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1 . INTRODUCTION 


Initial work performed under this contract (in response 
to SOW Tasks Phase A, B, and C (Item 1) consisted of conducting 
a survey and analysis of the existing methods, tools, and 
techniques that were being currently employed in the development 
of software. As a result of this effort, we made the following 
recommendations for the construction of reliable software which 
pertain to all phases of the software development cycle: 

• The software requirements stage should result in a 
structured, formal document which leads naturally 
into the software specification stage. It should 
be produced by an experienced analyst working in 
conjunction with the user. Origination of key soft- 
ware testcases should be an integral part of this 
stage. 

• Software functional design specifications should 
be carried out through a formal language which is 
capable of reflecting fidelity of design with soft- 
ware requirements. 

• Program code should be implemented using a struc-: 
tured programming language in which control struc- 
tures are operationally apparent and as few in 
number as tolerable. Hence a structured prepro- 
cessor should be employed for code implementation 
if a structured compiler language isn't available. 

• A programming language which promotes standard- 
ization of methods for accessing and operating 
on stored data bases such as the CODASYL Data 
Manipulation Language should be adopted and 
employed for purposes of data base verification. 
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• Software testing should be automated to establish 
user confidence while minimizing cost . Both 
static and dynamic testing are required. A 
static analyzer should enforce programming 
standards, while a dynamic analyzer should 
check the reliability of the code during execu- 
tion. Structural and requirements testcase gen- 
erators would greatly enhance the utility of the 
analyzers. A structural testcase generator pro- 
duces data to test as many branches of the code as 
possible and should be employed for determination 
of software reliability. A requirements testcase 
generator produces data to determine the consis- 
tency of the code with the software requirements. 

• Maintenance documentation needs to be an integral 
part of software. Documentation guidelines need 
to be established. 

As work progressed, we translated our analysis results 
into viable software designs for three of the SSES tools. This 
work was done in accordance with SOW Tasks Phase A, items 1, 3, 
4a, 4b, 4e, and 4f and Phase C, items 1 and 2. In the remainder 
of this report, we present functional software designs for the 
Software Specifications Language (SSL) (including a language 
reference manual) and the Data Base Verifier Subsystem (DBVS). 

In addition, a detailed (build-to) software design is described 
for the new capabilities to be incorporated into the static 
analyzer, FACES (FORTRAN Automated Code Evaluation System) . 
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2. SOFTWARE SPECIFICATION 


A primary goal of the SSES system is to provide early 
sol'Lware feasibility and testing. Commensurate with this goal 
wo have defined the Software Specification Language (SSL) for 
which the design is contained within this section. SSL is 
capable of representing all the information inherent in a 
functional block diagram of a software system. In addition, it 
j.s capable of (a) explicitly denoting the internal structure of 
data, (b) more completely denoting module interdepend.aicies , and 
(c^) expressing the input and output variables of each module. 
However, the most distinctive aspect of the language is the 
ability to attach requirement attributes to modules and vari- 
able.s which may be used in performing consistency checks. 

The experience gained thus far in using SSL indicates 
that it requires slightly more effort than is normally applied 
to I’unctional design. However, the effort is rewarded during 
detailed design as the module interconnections are much more 
evident and module functions tend to be more uniform and 
tractable. 
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2 . 1 


THE LANGUAGE 


2.1.1 I ntroduction 

SSL (Software Specification Language) is a new forma- 
lism for the definition of specifications for sof twar 3 systems. 
The language provides a. linear format for the representation 
of the information normally displayed in a two-dimensional 
module inter-dependency diagram. In comparing SSL to FORTRAN 
or AIiGOL, one finds the comparison to be largely complementary 
to the algorithmic (procedural) languages. SSL is capable of 
representing explicitly module interconnections and global 
data flow, information which is deeply imbedded in the 
algorithmic languages. On the other hand, SSL is not designed 
to depict the control flow within modules. We refer to the 
SSI, level of software design which explicitly depicts inter- 
module data flow as a functional specification. 

We wish to express our appreciation to Mr. Bobby 
Hodges of Data System I.abortory, George C. Marshall Space 
Flight Center for his guidance and support in the performance 
of this task. 

2.1. 1.1 Need for SSL 

The current state of the art in software development 
permits insufficient formal evaluation prior to implementation. 
Such questions as: 

• Are all requirements fulfilled? 

• Have all software elements been defined? 

• Are the element interconnections consistent? 

cannot be answered in a manner that is independent of the 
designer's opinion. The intent of SSI, is to formalize, through 
a Janguage, the statement of the functional specification for 
a software system. Given this formal statement expressed in 
SSL and a translator for the SSL language, an independent 
evaluation of the softw^are m,ay begin much earlier in the 
development cycle. 

JI/-^ 
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In addition to evaluation, other aspects of SSIi can 
aid both the designer and implementer. Several things that 
are characterist j cally omitted or inadequately performed 
during early design but required in SSIi are: 

• A complete and consistent statement of the 
software requirement 

• Unamtiguous communication of software organiza- 
tion to the detailed designer 

• Enumeration of intraprogram consistency checks 

(assertions) useful during checkout. 

A translator also provides tables and summaries for the final 

software documentation and a software element cross reference 

file. The latter could be used to statically verify the 
fidelity of the final code to original specifications. 

2 . 1 . 1 . 2 Unique Features of SSL 

The major contribution of SSL is the formal approach 
it brings to a phase ot softw^are development previously 
relegated to heuristic techniques as discussed above. Within 
this framework, there are several unique technical features 
possessed by SSI,. First, the projection of a specialized 
form of software requirements onto the objects being defined 
establishes a rationale for the software structure not present 
in other methodologies. These requirements are an important 
aspect of consistency checking when evaluating a specific 
functional design. Second, the incorporation of levels of 
abstractions directly in a design methodology is a step forward 
in software engineering. Lastly, an automated SSL translator 
is being designed that is one of several interlocking software 
design and evaluation tools collectively called Software 
Specification and Evaluation System (SSES). SSES includes a 
static code analyzer, a dynamic code analyzer, and a test 
case analyzer. The specific capability that SSL brings SSES 
is the ability to test and evaluate software design early in 
the development cycle. 

JI/— 
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SSI, also incorporates a flexible data abstraction 
capability and places emphasis on assertions as a means of 
describing the dynamic behavior of the software being designed. 
Although neither of these is unique, they are relatively new 
concepts in the field of computer science. 

2. 1.1. 3 Background 

In evaluating a new software system, particularly a 
programming language, it is important to trace the historical 
developments to which it relates and upon which it is based. 

The Mil, (Module Interconnection Language) system [l] was a 
principal contributor to the concepts of data creation and 
data availability restrictions among modules within SSL. 
Guidelines imposed for the partition of programs into sub- 
systems are derived from the principles embodied in the concept 
of levels of abstraction [2] . Module descriptions in SSL 
are a linearlized form of the information available in the 
two-dimensional diagrams referred to as structure charts [3 ]. 

The data description capability is largely the same as that of 
PASCAI, [ 4 ]. The syntax for expressions is derived from, but 
not identical to, that of ALGOL 60 [S]. Assertions in SSL 
have the form and appearance of those in the language 
NUCI,EUS [6], 
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2.1.2 The Grammar 

The material in this section is arranged in the form 
ol a reference guide to the language, and not tutorially in the 
manner of a user's manual. To aid the reader, a cross reference 
index is provided in the last section. 

2. I. 2.1 Metalanguage Description 

For the purposes of automatic translation and unambig- 
uous communication, it is desirable to express SSL via a formal 
grammar. The vehicle selected for this purpose is the Backus- 
Naur-Form (BNF) metalanguage [5], BNF has the advantages of being 
well known and compact in representation. In addition, most 
formal methodologies for analyzing grammars are based upon 
BNF representation. 

Any nontrivial language contains an infinite number of 
legal sentences. Each sentence, in turn, is composed of the 
concatenation of strings; strings are composed of characters. 

A grammar uses strings as operands and combines them under the 
f)peratlon of concatenation to finitely depict, all legal senten- 
ces. The way in which this is done in BNF can best be inter- 
preted via an example. Consider the following production: 

<ab> : : = a | b | <ab> a 

Sequences of characters enclosed within the brackets < >repre- 
sont metalinquistic variables called nonterminal symbols. The 
marks and "j" are metalinquistic connectives meaning "is 

composed of" and "or" respectively. Any string not a nonterminal 
or connective denotes itself and is called a terminal symbol. 
Juxtaposition of symbols between connectives in a formula, such 
as the example, signifies that the symbols must be in the exact 
order denoted. The above production indicates that <ab> may 
have the values; 


2^5 


a 


0 3 . ^ 2L3. j y • • ■ 

• b, ba, baa, ... 

In BNF, the null string is designated by <empty> 


SSL is represented as a context-free grari*;nar which 


riKjans : 


• There exist a finite number of productions 
of the type of the above example. 

• The left part of each production (i.e., left 
of ; :=) consists of a single nonterminal 
symbol. 

• There exists a unique nonterminal symbol (called 
the distinguished symbol) which is in the right 
part of no production except its own. 

2. 1.2. 2 Overview of SSL Grammar 

Prior to examining the detailed structure of SSL com- 
ponents, it will be useful to identify the overall structure of 
a software specification expressed in SSL, Figure 2-1 depicts 
th() sequencing of the syntactical items used to describe an 
SSL specification. 

A specification consists of one or more subsystems, 

(rach but the first having a name. The first subsystem is 
rol’erred to as the "main" subsystem and each subsystem is 
composed of a preamble and one or more module descriptions. 

The preamble defines the local environment for the subsystem 
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Syntactical Overview of an SSL 


Specification 












(constants, requirements, data formats, etc.) and the module 
descriptions indicate operational aspects of program units 
(program units are subprograms, procedures, etc.). 

In the following subsections, the detailed syntactical 
descriptions will be presented. 

2, I .2.3 Basic Vocabulary 

The basic vocabulary of SSL consists of special 
symbols, letters, digits, and reserved words. Each special 
symbol (Table 2-1) is primarily a single character except 
where limited computer character fonts require the concatena- 
tion of two characters. Where a special symbol consists of 
more than one character, it must be written without an inter- 
vening blank. Subsequently, special symbols other than 
”((?", and will be referred to as delimeters. Each char- 
acter in Table 2-1 is available within the ANSI standard codes 
for ASCII-8, EBCDIC-8, and HOLLER I TH- 2 56 . Substitutions 
may be necessary if an SSL translator is implemented in an 
environment not conforming to the standard character codes. 

Letters and digits do not have individual meanings 
but are used to construct identifiers, numbers, and reserved 
words. The following basic productions enumerate these ele- 
ments of the vocabulary: 

<letter> ::=a|b[ ...]z 

<digit> : 0 i 1 1 ... [9 
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TABLE 2-1 SSL SPECIAL SYMBOLS 





C 

] 

<= 

>= 
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Reserved words (Table 2-2) are composed entirely of 
sequences of letters. In this document, they are normally 
underlined. A reserved word may not contain imbedded blanks 
and must always be followed by a blank or a delimeter. 

The construct 

/* any sequence of symbols not containing "*/" */ 

may be inserted between any two identifiers, numbers, delimeters, 
or reserved words. It is called a comment any may be removed 
from the program text without altering its meaning. 

2. 1.2.4 Basic Language Elements 
2. 1.2. 4.1 Identi'fiers 
Syntax 

<identifier> : := <letter> | <identif ier> <letter> 

I <identif ier> <digit> | <identif ier> _ 

Examples 

Legal 
a 

b27 

cr 14dr 


Jlr 
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Illegal 

5ad 

sr$p 


TABLE 

2-2 SSL RESERVED 

WORDS 

Access 

Fulfil 

Transduction 

Accesses 

Fulfills 

Transductions 

Analog 

Global 

Transmit 

And 

Implies 

Transmits 

Array 

In 

True 

Assume 

Input 

Type 

Assumes 

Inputs 

Types 

Boolean 

Integer 

Use 

Case 

Iteratively 

Uses 

Char 

Modify 

Using 

Conditionally 

Modifies 

Variable 

Constant 

Module 

Variables 

Constants 

Of 


Constraint 

Or 


Constraints 

Output 


Create 

Outputs 


Creates 

Real 


Digital 

Receive 


Doubleprecision 

Receives 


End 

Record 


Entry 

Requirement 


Equ 

Requirements 


Execute 

Satisfies 


Executes 

Satisfy 


False 

Set 


File 

Sub jectto 


For 

Subsystem 


Forall 

Text 


From 

To 
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REPRODUCIBILITY OF T;F 
— ORiUINAL rAiiii; i« i^uuK 

Semantics 

Identifiers must begin with an alphabetic character 
and contain only letters, digits, and the symbol. The 

latter Is known as the break character. Identifiers have no 
inherent meaning, but serve as identification for variables, 
modules, subsystems, and other elements of a software specifica- 
tion . 

Identifiers may be of arbitrary length but must be 
unique within the first twelve characters. No identifier may 
be equivalent to the first twelve characters of a reserved word. 
The same identifier may not be used to denote two different 
quantities within a subsystem with the exception of field names 
in different records. 

2. 1 . 2 . -1 . 2 Numbers 

Syntax 

< unsigned integer> : :=<digit> | <unsigned integer> 

<digit> 

< sign >;:=+[ 

< exponent part > : : = e <unsigned integer > 

I e <sign> <unsigned integer> 

I d <unsigned integer> 

I d <sign> <unsigned integer> 

< decimal number > : : = <unsigned integer > 

I <unsigned integer> . 

<unsigned integer> 

< unsigned number > : : = <decimal number > 

I <decimal number> <exponent 
part> 

JI/- 
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Examples 


Legal 

57 

14dl0 
3.7 e-5 
0.2 


Illegal 

3,746 

XII 

e+7 

.14 


Semantics 

Decimal numbers have their conventional arithmetic 
moaning. The exponent is a scale factor expressed as an integal 
power of 10. A number expressed with neither a scale factor nor 
a decimal fraction is assumed to be of type integer. A number 
which uses the "d" form for the exponent part is assumed to be 
doubie precision. Otherwise, the number is assumed to be type 
real. Note that if a number contains a decimal point, at least 
one digit must precede and succeed the point. 

2.]. 2. 4. 3 Logical Values 

Syntax 

<logical value> : := true | false 
Semantics 

' Logical values have their conventional meaning and may 
be defined by describing their combination under the operations 
"union" and "intersection". The union of the logical value true 
with any other logical value always yields the result true . The 
intersection of the logical value false with any other logical 
value always yields the result false. 
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2. 1.2.5 Requirement Declaration 


The several parts of the requirement declaration are 
used to identify the data flow between the software package 
being described and other parts of the total system. In add- 
ition, they identify processing steps (called transductions) 
and restrictions (called constraints) which are attached to both 
modules and variables. 

Syntax 

<requirement declaration> ::= <requirement or 

requirements> 

<requirement statement group> end 

<requirement or requirements> : := requirement 
I requirements 

<requirement statement group> ::= <requirement 
statement part> 

I <requirement statement group> ; 
<requirement statement part> 

<requirement statement part> : ; = <input part> 

I <output part> j <transduction part> 

) <constraint part> 

2. 1.2, 5.1 Input and Output Parts 

An input is a system level input (or stimulus) which 
a software package receives from an external source. An output 
is a system level response which has a purpose beyond the 
immediate concern of the software package being described. 


JI/ 
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Syntax 


<input part> : : = <input or inputs > <entire 

variable list> 

<output part> : : = <output or outputs > <entire variable 

■ k 

list> 

<input or inputs> :: = input [ i^' vputs 

<output or outputs>:: “ output [ outputs 

Examples 

, input state_vector ; 

, inputs mass, velocity, distance ; 

, output concordance_list ; 

Semantics 

A variable may be in both an input and an output list. 

A variable in an output list not used within the subsystem 
other than in the module in which it is initialized is not 
required to have a requirement transduction attribute. The 
struc\ture of all variables in input and output lists must be 
described within the variable statements of the subsystem pre- 
amble. Each subsystem preamble must have a requirement declar- 
ation with an output part. 

2 . 1 . 2 . 5 . 2 Transduction Parts 

Transductions are identifiers representing processing 
steps. They are derived by first writing a high level pseudo- 
program t(^ "transduce" the input variables into the output 
variables and then extracting and listing the major verbs of 
the program. Just as the processing steps of the pseudo-pro- 
gram may be nested, the transductions may likewise be nested. 
Ideally, for each subsystem there should be from three to 
seven transductions that are not nested within any others. 

JI/— 
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Syntax 


j < transduction part> : : = <transduction or 

transductions ^ 

! 

<transduction clause> 

I 

I <transduction part> ; <transduction 
clause > 

< transduction or transductions >:; = transduction 

I transductions 

< transduction clause> : : = <transduction list> 

I <transduction list> <transduction 

list > 

< transduction list> ; : = <transduction identifier> 

I <transduction list >, <transduction 
identif ier> 

< transduction identifier >:: = <identifier> 

Examples 

9 transduction sum__expense , sub_deduct ^ tax_compute; 

write__pay check ; 

• transductions save_options; read_card ^ parse; 
Semantics 

Within a transduction clause, each processing step re- 
presented by a transduction identifier to the left of must 

bo a substep of the processing steps listed on the right of in . 
Each transduction id'jintifier represents a unique processing step, 
but may be reused to show different substep relationships. Sub- 
step relationships must be consistent, i.e., the complete set of 
substep relationships partially order the transduction identif- 
iers. 

JI/~^ 
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2. 1.2. 5. 3 Constraint Parts 
Syntax 


•- c'fjnsirai nt part> ;:= <constraint or constraints> 

< constraint list> 

< constraint or constraints >::== constraint 
i constraints 

< constraint list > ::= <constraint identifier > 

|<constraint list >, <constraint 
identifier> 

< c.onstraint identifier> ::= <identifier> 

Example s 

• constraint carpool_size ; 

• constraints raax_targets, minimum_distance ; 

Semantics 

3ach constraint identifier defined must be attached 
as an attribute to some module in the subsystem. 

2,i.2.6 Data Type and Variable Declarations 

Explicit description of data and the ability to define 
and u.sc new data types is one of the greatest assets of SSL. 

A new data type may be described directly as part of a variable 
declaration, or described independently for subsequent use. 

. Syntax 

< type- declaration> : := <type or types> 

<type definition> 

|< type declaration> ; <type definition> 

< type or types> : := type | types | global type 

[ global types 

J:/- 
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< l.ypo definition> : := <identifier> = <type> 


Lypc)>::= <simple type> | <structured type> 
j <pointer type> 

<var;lab3e declaration> : := <variable or variables> 
<variable definition> 

I <variable declaration> ; <variable definition> 

< variable or variables> variable [ variables 

< var i ab] e def inition> : <identifier list> :< type> 

|<identifier list> : <type> ; <for clause> 
I<identifier list> : <type> ; <subjectto clause> 
|<identifier list> ; <type> ; <for cla-use>; 

<subjectto clause> 

< I'or clause> : :== for <transduction list> 

<sub.jectto clause> : := sub jectto <assertion list> 

< assertion list> <assertion> 

1< assertion list> ; <assertion> 


< identifier list> : := <identifier> |<identifier list> , 
<identif ier> 


Semantics 

A type declaration list is used to define new data 
types. Each type is named and may be referenced by the identi- 
fier to the left of in the <type definition> production. 

The normal scope of a type identifier is the subsystem in which 
it is defined. However, the scope of a global tj^pe is the 
entire SSL program. Global types may be defined only in the f 

main subsystem. 



A data type need not be named if it is defined in- 
trinsic to the variable declaration. Both type and variable 
declarations may use data types defined and named elsewhere. 
J'lxamples of both are given in the following subsections. 

The <for clause> of the variable declaration is used 
to attach requirement attributes. Requirement attributes limit 
the availability of variables within the modules of the sub- 
system. All variable declarations must contain a for clause 
with the exception of output variables identified in the require- 
ment statement. 

The <subjectto clause> identifies the global assertions 
associated with the variables being declared. A global 
assertion is one that must be true upon exit from the module 
creating the variable, and true on both entry and exit of modules 
using the variable. 

2,1. 2.6.1 Simple Types 

Simple types are data types for which the designer, 
using SSL, need not define the internal structure or the inter- 
nal structure has previously been defined and named. 

Syntax 

< simple type> <basic type> |<scalar type> 

I <subrange type> ] <type identifier> 

< type identifier> : := <identifier> 

Semantics 

, A type identifier must previously have been used to 

the left of an "=" in a type definition. 

REPRODUCIBILrrY OF THE 
ORIGINAL PAGE IS POOR 
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2.1 ,2.6.1 .'1' ' l?asic Types 

'The basic data types are those which are implicity 
donned b'y., the SSL language. 


< basic type> integer | real [ boolean 

I doubleprecision | char | analog | text 


Examp] es 


variables I, J, K: integer ; for count_people j 


variables 


height : real ; 

for record_status ; 

sufojectto height >0.0 ; 

height <= 10.0 ; 

employed: boolean ; 

for record status ; 


Semantics 

The types integer , real , boolean , and doubleprecision 

have the conventional meaning. The type char indicates a 

single unit of hollerith information. Type text indicates 

hollerith dat'a with unspecified length. Since the length of a 

text item vati'^s , it may not be combined with other variables 

in forming ^structured data types. The type analog designates 
1 / 

a data item \whlch contains analog signal information. Like the 
text type it may not be combined with other variables to form 
structured tyt>es. 
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2,1. 2. G. 1.2 Scalar Types 


Scalar types are used to designate a finite number of 
disjoint .states which a variable may represent. In conventional 
programming languages, it is customary to declare the variable 
oC type intege r and assign it only the cardinal numbers 1, 2 ,.,., 
n where each value represents one state of the several possible. 

Syntax 

< scalar type> : := ( <identifier list> ) 

Examples 

♦ type marital_status = (single, married, divorced); 

vari able ms : marital_status ; for emp_record; 

• var table color: (Eed, blue, yellow, green) ; 

Semantics 

Conceptually, the elements of scalar types are ordered 
regardless of whether or not the underlying set of states is 
ordered. The order is always the same as that of the identifiers 
in the identifier list. This enables a designer to use rela- 
tional tests (< ,>, etc.) in assertions involving scalar type 
variables^ 

2. 1.2. 6. 1.3 Subrange Types 

Subrange types are used to designate a subset of integ- 
or.s or scalars which a data item may assume. 

Syntax 

< .subrange type> ::= <constant> .. <constant> 

< constant> ; : = <unsigned integer> 

I <sign> <unsigned integer> 

|<constant identifier> 
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I <sign> <constant identif ier> 

I <logical value> 

< constant identif ier> ::= <identifier> 

Examples 

» variables weight: 10.. 350; for ins_compiite ; 

dependents: 0..15; for tax_compute; 

• l^ypo color = (purple, blue, red, yellow, green, black); 
var j able primary_color : blue . .green; 

Semantics 

A subrange simply indicates the least and largest con- 
stant values an item may assume. The lower bound (left-most 
constant in the production) must be less than the upper bound. 

A subrange with bounds expressed in types other than integer or 
scalar is not permitted. 

Constant identifiers may arise from two contexts. The 
first is the appearance of an identifier to the left of in 

a constant declaration. The second (illustrated by the above 
example) is the appearance of an identifier as a scalar element. 
Constant identifiers arising from the second context may not be 
proceeded by a unary sign. 

2, 1.2. 6. 2 Structured Types 

A structured type is a data type composed of more 
elementary data types. 

)F THE 

FO'lE 
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Syntax 

< structured type> : := <array type> | <record type> 

I <digital type> j <set type> 
l<sequence type> 

Semantics 

An SSL structured data type is used to indicate the 
general form and content of a data structure, not precise imple- 
mentation word and storage formats. In SSL, the following 
definitions are used: 

A fixed number of data items, all of the 
same type and length and accessed by 
computed index. 

A fixed number of data items, each of fixed 
length, and each equally accessible. 

A record having additional restrictions which 
are discussed in a subsequent subsection. 

An element of the powerset of a finite number 
of basic elements. 

A variable number of data items, all of the 
same type and length; however, each element 
is not equally accessible at all times. 

Stronger connotations (such as elements of an array are seq- 
uentially stored) arenot implied by the semantics of SSL. 


Jlr 
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2 . 1 . 2 . 6 . 2 . 1 Arrays 


An array is a fixed number of data elements, each of 
the same type and length and each equally accessible. Elements 
of an array are ordered and each element is accessed by a 

cardinal number called its index. 

Syntax 

< array type >:;= array [^<index list>^ of 

<component type> 

< i ndex list> : := <index type> [ <index list> , 

< index type> 

< index type >::= <siraple type> 

< component type> : := <type> 

Examples 

• va-riabi e matrix: array Ql. .10, 0. • 20^ of real ; 

for ta ; 

• people = (adams, buckles, Jones, smith); 
variable employee; array J^peopleJ of 1..50 ; 

for ta; 


JI/ 
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Semantics 


Index types must have a finite range and be ordered. 
Tins roctuirement eliminates index type of integer, real, and 
doublet-precision. However, subranges of integers are permitted. 
For the purpose of ordering, false <true for boolean type 
1 ndi ces . 

2. 1.2. 6. 2. 2 Records 

A record is a structure containing a number of com- 
ponents called fields. Fields are not constrained to be of 
idcntie.al type but must be of fixed length. A single record 
ty|)o is permitted to have variants. 

Syntax 

< record type> ; ;= record <field list> end 

< field list> <fixed part> | <fixed part> ; 

<variant part> | <variant part> 

< fixed part> <record section> |<fixed part> ; 

<record section > 

< record section> <field identifier list> : <type> 

< fiel d identifier list> ::= <field identifier> 

I < field identifier list> , <field identifier> 

< vari ant part> : case <tag field> <type identifier> 

of <variant list> 

< variant iist> : <variant> j <variant list> ; 
<variant> 

< tag f ield> : := <field identifier> 

< f i eld identif ier> : := <identifier> 

< varian1j> ; ;= <case label list> : (<field list> ) 

j <case label list> :( ) 

< case label list> ; <case label> I <case label list> 

< case label> 

< case iabel> : := < constant> 
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Type employee = Record 

Number : Integer ; 

Salary : Real ; 

Name : Array Cl.. 243 of char 
End ; 

Variable machine part: Record 

Part_No , Order Quantity : Integer ; 
Weight : Real 

End ; 

for customer_billing ; 


Type complex = Record real_part, imag part: real End ; 


♦ Type farm =(peaches, cotton, soybeans); 
Type land__use = Record 

Owner Name : Array [i..i2ii of char ; 
Plot No: Integer ; 

Case Crop :Farm of 


peaches : ( tree_count : Integer ) ; 
cotton, soybeans : (plant date: Integer ; 
herbicide, insecticide rboolean) 


End; 


Variable sizes : Array |^1 • • 10^ of Record 


Height ■’ Integer ; 
Weight : Real 
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for health f ile_update ; 


sub.jectto height >0; height <120; 

weight >0.0; weight <500.0 ; 

Semantics 

Fields may not be of basic types text or analog . A 
record may be a component of another record, but a digital type 
may not. The scope of a field identifier is the smallest record 
in which it is defined. Field identifiers with disjoint scopes 
may be reused. Access of a component is always by the field 
identifier and never by a computed value. 

The type associated with the tag field of a variant 
must contain only a finite number of elements. This limits it 
to boolean, subrange, and scalar. All elements of the type 
must appear in some case label list of the variant. If the 
field list for case label L is empty, the form is: 

L : ( ) 

A record may contain only one variant part and it must 
succeed the fixed part. However, a variant may contain variants. 
That is, it is possible to have nested variants. All field 
names of the same record must be unique even if they are in 
different variants. 

2. 1.2. 6, 2. 3 Digital Types 

Digital types are a restricted form of records to 
represent real time digital signals. 

Syntax 

<digltal type> : := digital <fixed part> end 
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• Variable Signal_In: digital 

Valve_l : boolean ; 

LOX_Switch : 1 . . 3 ; 

Command: (Idle, stopped, running) 
End ; 

for check_status; 

( 

Semantics 

Due to their physical interpretation, the type of 
components within digital types may only be boolean, scalar 
or subrange. Digital types may not have variant parts and 
they may not be used as components of any other type. 

2. 1.2, 6. 2. 4 Set Types 

Set types represent elements of powersets over a 
finite set of elements called the base type. Conceptually, 
a set type variable may be viewed as a bit string of length 
equal to the number of elements in the base type. Each bit 
is associated with a unique element and is "on" or "off" 
if the element is a member or not a member of the powerset . 

Syntax 


<set type> : := set of <base type> 

<base type>::= <siraple type> 

Examples 

• Type members = (father, mother, big_sister, 

little_sister, big__sister, little_brother ) ; 
Variable family: set of members; for arrange; 

• Va-riable Even_numbers : set of -10. . 10; 

for compute_something . 


Semantics 


The base type must be either scalar or subrange. 

2. 1.2. 6. 2. 5 Sequence (File) Types 

A sequence differs from an array in tha.t it may vary 
dynamically in length and is referenced through a "windov?” 
called its buffer (not by computed index). Examples of physical 
representations of sequences include linked lists and mass 
storage files. 

I 

Syntax 

< sequence type> : := <file or sequence> _of <type> 

< file or sequence> : := file | sequence 

I 

Examples 

• Variable Assembly: sequence of record 

part name: array of char • 

order_no: integer ; 

drilled, punched, stamped, purchased: 
boolean 

End ; for update__orders ; 

• Type roster_entry = record 

name: array [l..20^_of char ; 
rank: 1..16; base_code: 1000.. 5000 

End ; 

Variable roster: file of roster__entry ; 

for assign_new_base ; 
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Semantics 


All components ot sequences must be of identical type 
and length. A sequence may not have sequence type or text type 
components. Furthermore, digital and analog types may not be 
combined as sequences . 

2. 1,2. 6. 3 Pointer Types 

Variables of type pointer are "bound” to a particular 
type. That is, the contents of a pointer is used to indicate 
a second variable, and the second variable is required to be of 
a predetermined, specific type. 

Syntax 

<pointer type> : ;= @ <type identifier> 

Examples 

• Type combination = record n, p: integer End ; 

Variable comb_ptr: @ combination; for select_band; 

• Type weather_station = record hi,lo: integer ; 

rain ; real End ; 

Variable ws__ptr: @ weather_station ; 
for record_temperature ; 

Semantics 

The contents of a pointer may be altered, but the 
data element the pointer indicates is always of the same type. 
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2.J.2.7 Constant Declarations 


In SSL, constant declarations may appear in the 
preamble of any subsystem and are used to communicate actual 
values or parameters to the detailed designer. Normally, 
a constant declaration would be used only for critical values 
for which the effects are to be isolated in the final code. 

Syntax 

< constant declaration> : := <constant or constants> 
cconstant definition list> 

< constant or constants> : := constant | constants 

< constant definition list> : := <constant definition> 

I <constant definition list> ; <constant definition> 

< constant definition> : := <identifier> = <constant> 

I <ident if ier> = <simple type> 

Examples 

• Constant a = 10 . 0 ; max_count = Integer ; 

• Constants Low = true ; 

Tax_ cut = 1 . . 5 ; 

Semantics 

An identifier declared equal to a simple type indicates 
that the exact value is not known at the time of specification, 
but will be provided before implementation. An identifier used 
in a constant declaration may subsequently be used any place 
that a constant (of the same type) may be used. 
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2. 1.2.8 Data References 


Data elements may be referenced by variable name, 
by selected component, or pointer. A variable has components 
only if it is a record, digital signal, file, or array. 


Syntax 

< varlable> : := <entire variable> 

I <component variable> 

I <referenced variable> 

2. 1.2. 8.1 Entire Variables 

< entire varlable> : ;= <identifier> 

Semantics 

A reference to an entire variable includes all fields 
of a record or digital signal, all elements of an array, or all 
records of a file. If the data element is a simple, unstruct- 
ured variable (integer, boolean, etc.) it may only be refer- 
enced as an entire variable. 

2.1. 2.8.2 Component Variables 


< component variable> <indexed variable > 

l<field designator> 

I <file buff er> 

< Indexed variable> : <array variable> 

[]<expression list>3 
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<array variable> : := <variable> 

<oxpre«sion list> ; := <expression> | <expression list> , 

<expression> 

<Iield designator> : := <record variable> . <field 

identif ier> 

<record variable> : := <variable> 

<file buffer> : := <file variable> @ 

<flle variable> : := <variable> 


Examples 


Char_Array to 
Inverse_Matrix [5, I, le] 

Employee .Name 

Owner [is] . Accessed_Value 
Name_Record -Character CO 
Transaction_Flle @ 

Transaction_File @ . Date 
Transaction__File @ . Date. Month 

Semantics 

Indexed variables have the conventional meaning. Field 
designators denote which field component of a record or digital 
signal type is to be selected. A file buffer variable designates 
the current active element of the sequence of elements that 
comprise the file. 
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Since arrays, files, and records can be combined in 
various ways (a record of records, file of arrays, array of re- 
cords, etc.) a component variable can be arbitrarily complex. 

It is recommended that data structures be as limited in complex- 
ity as the problem permits. 

2.. I. 2, 8. 3 Referenced Variables 


<referenced variable> ::= <pointer variable> @ 
<pointer variable> ; := <variable> 

Examples 

Symbol__Pointer ® 

Student_Name [e3 @ 

Assembly®. Manufacturer® 

Semantics 

The data structure denoted by the contents of the 
pointer variable is substituted lor the referenced variable 
in expression evaluation. 

2.1.2. 9 Expressions and Assertions 

Expressions arise in two contexts: subscripts of 

arrays and as terms within assertions. Assertions may appear 
in either variable declarations or module descriptions. 
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2. 1.2. 9.1 Arithmetic Expressions 

Arithmetic expressions in SSL are similar to those in 
other high level languages. Results of expressions are single 
valued with type determined by the operation and the con- 
stituent operands. 

Syntax 

<arithmetic expression> <term> j <sign> <term> 

I < arithmetic expression> <sign> <term> 

<term> : ;= <factor> j <term> <multiplying operator> 
<factor> 

<factor> : := <primary> [ <factor> <primary> | <set> 

<primary> <constant identifier> | <unsigned 

number > j <variable> | < function designator > 

I ( <arithmetic expression> ) 

<set> : := j^<element list>[] 

<element list> ; := <empty> | <eleraent> | <element 
list>, <element> 

<element> : ;=<expression> | <expression> .. 
<expression> 

< multiplying operator> ; * ]/ 

<f unction designator> :;= <function identifier> 
(<expression list> ) 

<function identifier> : := <identifier> 

J:/- 
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Examples 


a + b 

3.0 * sin ( r + 1.0) 

2 * (ifix(c) + blank_common . i count ) 

name . f ieldl 

name_set + frec^ 

Semantics 

Mixed mode expressions are prohibited with the excep- 
tion of the exponentiation operator as indicated in Table 2-3. 
In Table 2-3, any operand of type integer may be replaced by 
an operand of type integer subrange. The symbol "dp" indicates 
double precision. The unary "+" may be used with any operand 
permit ling a unary but is semantically superfluous (i.e. + 

is the; identity operation). If a type is not included in the 
operand type columns of Table 2-3 then its use with the desig- 
nated operator is not permitted. Note, however, that integer 
and integer subrange are interchangable . 

SSL does not contain intrinsically defined functions. 
All function identifiers are accepted, but it is suggested that 
those embodied in the proposed implementation language be 
adopted for each specification. Function types are not explic- 
i ty declared, but must be consistently used throughout the 
spool I’ication. In addition to the basic types (integer, real, 
etc.), the permissible function types include scalar and sub- 
ranges of integers and scalars. 
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TABLE 2-3 ARITHMETIC OPERATIONS 


VI '=OP” V2 


Operator 

Operation 

VI Type 

V2 Type 

Result Type 

- 

Arithmetic Negation 


Integer 

Real 

dp 

Integer 

Real 

dp 


Addition, Subtraction 

Integer 

Real 

dp 

Integer 

Real 

dp 

Integer 

Real 

dp 

+ j - 

Set Union, 

Set Difference 

Set 

Set 

Set 

*./ 

Multiplication , 
Division 

Integer 

Real 

dp 

Integer 

Real 

dp 

Integer 

Real 

dp 

* 

Set Intersection 

Set 

Set 

Set 

*4= 

Exponenciat ion 

Integer 

Real 

Real 

dp 

Integer 

Integer 

Real 

Integer 

Integer 

Real 

Real 

dp 
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2. 1.2. 9, 2 Boolean Expressions 


Combining arithmetic expressions with the boolean 
operations produces the expressions used in SSL assertions 
and array subscript lists. 

Syntax 

< expression> : <implication> ] <expression> equ 

<implicat ion> 

implication > <boolean term> ] <implication> 

implies <boolean term> 

<boolean term> ;:= <boolean f actor> | <boolean term> or^ 
<boolean factor> 

<boolean factor> : := <boolean secondary> j <boolean 
factor> and <boolean secondary> 

<boolean secondary^ • *= <boolean primary > |-i<hoolean 
primary> 

<boolean primary> <logical value> | <arithmetic 

expression> | <relation> | (<assertion> ) 

<relation > ::= <arithmetic expression><relational 
operatorxarithmetic expression> 


<relational operator^ : := < <“ ~l 


2-38 


j7/ 



T 


Examples 

Rate =7.0 

Value and Qual 

a>b Implies c>0.0 

S — 1 = t Equ p<t 

Color ^ Qred, green, yellowj 

abs (buffer ©.velocity) <16.0 and weight >= 14,0 


Semantics 

The arithmetic and boolean operators are grouped into 
hierarchial levels as exhibited in Table 2-4. Operations are 
performed in the order of highest hierarchial level first 
followed by equal hierarchial levels from left to right. This 
sequence may be overridden by parentheses, in which case the 
innermost operations are performed first. The meaning of the 

! 

logical operators (not), and , or, implies, and equ (equi- 
valent) is given in Table 2-5. 

Table 2-6 depicts the required operand types for the 
boolean and relational operators. For set types, the symbols 
"CD" empty set. When comparing set types to 

scalars, the base type of the set must be the same as that of 
the scalars. The operators <, <=, =, >= , >,-7 = stand for less 
than, less than or equal, equal, greater than or equal, 
greater than, and not equal respectively. Relational operators 
(other than ) may be used to compare arrays of equal length 
composed of characters, in which case they denote alphabetical 
ordering. 
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TABLE 2-5 LOGICAL OPERATOR TRUTH TABLE 


bl 

false 

false 

true 

true 

b2 

false 

true 

false 

true 

—1 bl 

true 

true 

false 

false 

bl And b2 

false 

false 

false 

true 

bl Or b2 

false 

true 

true 

true 

bl Implies b2 

true 

true 

false 

true 

bl 1^ b2 

true 

false 

false 

true 
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TABLE 2-6 BOOLEAN AND RELATIONAL OPERATIONS 




VI "OP" 

V2 


Operator 

Operation 

VI Type 

V2 Type 

Result Type 

<, <, =, 

Compare 

Integer 

Integer 

p 

V 
II 

V 

j 

II 


Real 

Real 




dp 

dp < 

Boolean 



Boolean 

Boolean 




Char 

Scalar 

Char 

Scalar 

1 

In 

Set Inclusion 

Scalar 

Set 

1 

r 



Set 

Scalar 

1 



Set 

Set i 

. Boolean 



Subrange 

Set 




Set 

Subrange 

L 

1 

Logical Inversion 

Boolean 

Boolean 

Boolean 

And 

Logical ’’And" 

Boolean 

Boolean 

Boolean 

Or 

Logical "Or” 

Boolean 

Boolean 

Boolean 

Implies 

Logical Impli- 
cation 

Boolean 

Boolean 

Boolean 

Equ 

Logical Equi- 
valence 

Boolean 

Boolean 

Boolean 
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2, I. 2. 9. 3 Assertions 

Assertions are conditions which may assume only true/ 
false values. They are attached to variables at their point 
of declaration and to modules. Module assertions depict entry 
and exit data conditions. 

Syntax 

<assertion> <expression><forall clause> 

< (’oral 1 clause> : := <empty> | forall identifier = 

<set> 

Examples 

• a £i^ =0.0 forall i = []l • • 

(b. c = t forall j = {^1,3,4. .loj ) forall 

k = (l6. .3 o3 

• big>small 

• code = 1 implies (eof equ true) 


Semantics 

The scope of the identifier in the cforall clause> is 
the assertion in which it is used and must not overlap that 
of a local or global variable of the same name. Its type is 
assumed to be the base type of the set within the <forall 
clause>. The set must represent a finite number of elements 
and may not be empty. 

The expression within the assertion may assume only the 
values true and false. If the <forall clause> is present, the 
expression is evaluated once for each unique value which the 
<forall identifier> can assume from the set. 
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2.1.2.10 Module Descriptions 


Modules are basic system objects in an SSL system 
description. In using SSL, one identifies for each module: 

• The module name 

• Input and output data 

• Conditions placed on data upon entry to and 
exit from' the module 

• Dependence of the module on environmental 

objects and other modules 

The rule of correspondence between input and output data is 
nol .stated in SSL. Its statement is a function of detailed 
dc.slgn. 

Syntax 

< modul e descript ion> ::= <module statement>; 

<module definition part> end 

<■ module definition part> ::= <module definition 
statement> I <module definition part> ; 

<module definition statement> 

< module definition statement> : := <assumes statement> 
[<satisfies statement >[ <fulf ills statement> 

I <accesses statement >| <modifies statement> 

[ <creates statement> [ <uses statement^ 

1 <receives statement> | <transmits statement> 
j <executes statement> 
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2.1,2.10.1 Module Statement 


The module statement is always the first statement 
or a module description. It identifies the module by name 
and declares the local variables (if any). 

Syntax 

< module statement> ::= <module or ent'nv> <module 
identifier> <release variable group> 

<module or entry> : module | entry 

< release variable group> : ;= <empty> | ( <release variable 
list> ) 

< release variable list> : <release variable> | <release 
variable list>; <release variable> 

< release variable> : ;= <variable > | <local variables> 

< 1 ocal variables> : <identifier list> : <simple type> 

< module identifier> ; ;=<identifier> 

Examples 

• module matrix_multiply ; 

• entr y push stack (stack_item: stack_entry ) ; 

• niodule permutation (m, n : integer ; elements : p_array ) ; 
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Semantics 


A module statement introduced by module can only be 
referenced from within the subsystem in which it is declared. 

A module statement introduced by entry can be refer- 
enced only from subsystems other than the one in which it is 
declared. 


Release variables occur both in module statements and 
virtual references within execute statements. Local variables 
within a release group serve strictly for communication bet- 
ween the module and those calling it. In this respect, they 
differ from global variables declared in the subsystem pre- 
amble which serve to communicate among modules having common 
requirement attributes. Local variable identifiers must be 
unique throughout a subsystem. Only the module statements 
introducing entry modules are permitted release variables 
which are not local variables. The variables of a release 
group for a module statement of an entry module must agree 
in type, number, and sequence to each virtual reference to 
it from other subsystems. 


2.1.2.10.2 Assumes and Satisfies Statements 

The assumes and satisfies statements specify truth 
conditions for data. 


Syntax 


< assumes statement> : := 
<assertion list> 

< satisfies statement> : 
<assertion list> 

< assume or assumes> : := 
< satisfy or satisfies> 


<assume or.-assumes> 

= <satisfy or satisfies> 


assume assumes 


: = satisfy [ satisfies 
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Examples 


• Assume a >0.0 ; 

• Satisfies big_sister aji family; count — j = 0 ; 
Semantics 

The assumes statement specifies data conditions 
that must be true upon module entry. The satisfies statement 
specifies data conditions that must be true upon module exit. 
Variables used in assertions must be either local variables 
in the release set or in the availability set pertinent to 
tho module. (The availability set consists of those variables 
having requirement attributes which subsume all requirement 
attributes of the module.) 

2.1.2.10.3 Fulfills Statement 

The fulfills statement attaches requirement attributes 
to a module. 

Syntax 

< ful fills statement> : <fulfil or fulfills> 
<requirement attribute list> 

< requirement attribute list> : ;= <attribute identifier> 
i <requirement attribute list> , <attribute 
identifier> 

<attribute identifier^ <transduction identifier> 

I <constraint identifier> 

<fulfil or fulfills> : fulfil I fulfills 
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Examples 


• fulfills size_constraint , cluster; 

• fulfil name_list ; 

Semantics 

All modules must have at least one transduction 
identifier attached as a requirement attribute. All attribute 
identifiers must be declared in the preamble to the subsystem 
in which the module is declared. 

2.1.2.10.4 Accesses Statement 

The accesses statement is used to indicate which 
environmental objects (chiefly peripherals) are utilized by 
a module . 

Syntax 

< accesses statement> ::= <access or accesses> 
<environmental object list> 

< access tor accesses> access | accesses 

<.environmental object list> : <environmental 

object identif ier> 1 <environmental object list> , 
<envirDnmental object identif ier> 

< environmental object identifier> : :=<identifier> 
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Examples 


• Access line_printer ; 

• Accesses real_time_clock , system_disk ; . 

Semantics 

For each environmental object there must be a unique 
identifier for which the scope is the entire specification. 

2.1.2.10.5 Receives and Transmits Statements 

The receives and transmits statements are used to in- 
dicate real time data activity such as is associated with 
telecommunications, analog, and digital signals. 

Syntax 

<receives statement> ::=j <receive or receives> 

<from clause> I <receives statement> ; <from clause> 

< from clause> <entire variable list> from 

<environmental object identifier> 

<transmits statement> ::= <transmit or transmits> 

<to clause> i <transmits statement> ; 

<to clause> 

<to clause> : := <entire variable list> 

<environmental object identifier> 


jf/ 
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'<rec',eive or receives> 


receive 


receives 


<Lratismi(, or transmits> : := t ransmit { transmits 

<entire variable list> ; := <entire variable> 

I<entire variable list> , <entire variable> 

Examples 

• Receive weight from strain_gage_l ; 

• Transmits course_correction ground_control ; 

Semantics 

The scope of the environmental object name is the 
entire specification. Note that components of structured 
variables may not be transmitted or received. 

2.1.2.10.6 Creates, Modifies, and Uses Statements 

The creates, modifies, and uses statements distinguish 
between input and output data variables. They may also in- 
dicate how the two are related in a manner short of a rule of 
correspondence. A complete rule of correspondence (algorithm) 
is a task of detailed design and not of SSL. 

Syntax 

< creates statement> ; := <create or creates> 

< create list> 

< modifies statement> ::= <modify or modifies> 

<modify list> 

JI/~ 


2-50 


<modify list> : := <variable listxusing clause> 
|<modify list>; <variable listxusing clause> 

<create list>::= <entire variable listxusing clause> 
I <create 1 ist> ; <entire variable listxusing clause> 

<uses statement > : := <use or uses> <variable list> 
•^create or creates> : := create | creates 
<modify or modifies> : modify | modifies 
<use or uses> :;= use I uses 




<using clause> ::= <empty> [ using <variable list> 

<variable list> : <variable> | <variable list >, 

<variable> 

Examples 

• create employee_array using name_file; 

• modi Ties count, fica_rate using tax_table, 

salary^scales ; 

•modify pressure -weight CO , names [loj • initials ; 

• uses cluster®, transaction_f ile ; 


j7/ 
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Semantics 


The order of the variable references in any variable 
list has no significance. . 

The variables within a using clause or a uses state- 
ment are input variables. A variable may be both input and out- 
put. An input variable in a using clause indicates that its 
contents are instrumental in determining the final contents of 
the output variables within the same statement extending to the 
first semicolon on the left. 

The presence of a variable in the output list of a 
creates statement indicates the first use (in a dynamic sense) 
of that variable. This does not mean, however, that the vari- 
able may not appear previously in the sequential listing of the 
SSL program. The implication of the creates statement is that 
all variables in the output list are first computed or initia- 
lized in the module being described. All variables declared 
in the subsystem preamble must appear as an output variable in 
exactly one creates statement within the subsystem unless it is 
a release variable of an entry module. 

All variables appearing in a creates, modifies or uses 
statement (other than the output list of the creates statement) 
must be in the availability set for the module. A variable is 
in the availability set of a module if the transduction require- 
ment attributes of the variable subsume all the transduction 
requirement attributes of the module. 


REPRODUCIBILITY OP THE 
ORIGINAL PAGE IS POOii 
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2. J. 2.10.7 Execute Statement 


The execute statement designates modules which are 
called by the module being described. It may indicate that 
.specific modules are called iteratively, conditionally, or 
both . 


Syntax 

< executes statement> : := <execute or executes> 

<call list> I <executes statement>; <call list> 

<call lisi;> : := <module reference list> | <module 
reference list> <call list tail> 

I <call list tail> 

<call list tail> : :=? <iteratively clause > 
j <conditionally clause> 

<iteratively clause> : := iteratively <module 

reference list> j iteratively <call list tail> 


< conditionally clause> : conditionally <module 
reference list> 

< execute or executes >:;= execute | executes 

<module reference list> : := <module reference> 

I <module reference list> , <module reference> 

<module reference> : := <concrete reference> 

I <virtual reference> 

J7/ 


2-53 


<C‘.oncrete reference> 


<module identifier> 


<virtuai reference> :;= <subsystem identifier> . 

<module identif ier><release variable group> 

Examples 

• Execute matrix_multipiy , cluster • group (pointer©); 

® Execute iteratively suba , subb ; 

conditionally subc, subd, sube; 

• Executes sqrt ; iteratively cos conditionally sin; 

Semantics 

The order of module identifiers in the module reference 
lists is not significant. The domain of either an iteratively 
or conditionally clause extends to the next semicolon. An 
iteratively clause may overlap another clause. 

Presence of a module identifier in a iteratively clause 
connotates that it is called from within a loop. Presence in 
a conditionally clause connotates the module is not always 
called. If present in neither, the module is called uncon- 
ditionally but not from within a loop. 

A concrete reference is a call to a module within the 
same subsystem. A concrete reference may never be to an entry 
module. A virtual reference is a call to a module of a 
different subsystem and must always be to an entry module. 


Jlr 
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Within the release variable group, the local variable 
format must be used for variables never before defined. A 
variable may have been defined in the preamble to the sub- 
system or in the last module statement. The entry module 
to which the virtual reference refers must have the same 
release list with respect to number, order, and type of 
variables. All variable types used in a virtual reference 
release list must be either intrinsically defined ( boolean , 
real , text , etc.) or global types. 

2.1.2.11 Subsystem Descriptions 

Subsystems are independent software units, each with 
ibs own requirement declaration. Subsystems may not share 
global variables but communicate via the release group var- 
iables of virtual references and entry modules. The only 
identifiers with scope greater than a single subsystem are 
global type identifiers, environment object identifiers, 
subsystem identifiers, and function identifiers. 

Syntax 

<subsystem description> ; := <subsystem preamble> ; 
<module description list> end 

^module description list> : := <module description> 

1< module description list>; <module 
description> 

< subsystem preamble> : := <preamble declaration list> 

1 subsystem <subsystem identifier> ; <preamble 
declaration list> 


JI/ 
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< subsystem identilier> 


<identif ier> 


<preamble declaration list> : := <preamtale declaration> 
j<preamble declaration list> ; <preamble 
declaration> 

< preamble declaration> <reduirement declaration> 

I *^type declaration> | <variable declaration> 
j<constant declaration> 

< subsystem description list> : ;= <subsystem 

description> I <subsystem description list> ; 
<subsystem description> 

< specif ication> : := <subsystem description list> 


Example 

• Requirement transduction sort_descend; input n, 
sort_array; output sort__array end ; 

Variable sort array: array [^1. . lOOoJ of real ; 
for sort_descend; 

sub.iectto sort arrayfi j >0.0 f orall i 
Cl..n-0; 

n;1..1000; for sort_descend; 

Module sort; 


fulfills 

accesses 

creates 

modifies 


sort__descend; 

card_reader, 1 ine_pr inter ; 
n, sort_array; 

sort_array using n, sort__array; 
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/ 


satisfies 


sort_array [i] >= sort_array 
forall 1 = [^l..n-l] 

End 


End 

End • 

} 

Semantics 

Each subsystem must have a requirement declaration 
that contains at least one transduction identifier and one 
output variable. There must also be at least one module 
description. The first subsystem declared (called the ’’main'' 
subsystem) does not have a subsystem identifier; all others 
must have a unique identifier. The scope of the subsystem 
identifier is the entire specification. 

The nonterminal symbol <specif ication> is the 
distinguished symbol of the SSL grammar. 


Jf/ 
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2.1.3 Example 


Tl){) oxampio of this section was selected to demonstrate 
both Lhc descriptive level of SSL and as mary language elements 
as possible. The requirement of the problem may be stated as 
follows 1^8^ : 

"A program is required to process a stream 
of telegrams. This stream is available as a 
sequence of letters, digits and blanks on some 
device and can be transferred in sections of 
predetermined size into a buffer where it is to 
be processed. The words in the telegram are 
separated by sequences of blanks and each 
telegram is delimited by the word 'ZZZZ'. 

The stream is terminated by the occurrence 
of the empty telegram, that is a telegram 
with no words. Each telegram is to be pro- 
cessed to determine the number of chargeable 
words and to check for occurrences of over- 
length words. The words 'ZZZZ' and 'STOP' are 
not chargeable and words of more than twelve 
letters are considered overlength. The 
result of the processing is to be a neat 
listing of the telegrams, each accompanied 
by the word count and a message indicating 
the occurrence of an overlength word." 

To complete the problem statement, several assumptions are 
n('c,essary. The following alternatives were selected for the 
purpose of this exposition: 
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• The character stream from which the telegrams 
are constructed resides on a drum having fixed 
length records; the record length itself is left 
as an implementation option. 

• The chargeable word count is the value to be 
printed and overlength words count as one word. 

• If a physical end of file is encountered before 
the logical end of the data stream, an error 
message and the partial telegram is printed. 

The software is organized into four modules as indicated 
by Figure 2-2. The purpose of each module is given in Table 
2-7. Figure 2-3 contains the SSL description of the telegram 
processor. The right margin of the statement listing contains 
reference notes to subsections containing detailed descriptions 
of the language elements used. 

A careful examination of Figure 2-3 will indicate an 
interesting application of the subsystem capability. The 
subroutines GET_CHAR and FILL_BUFFER occupy a separate sub- 
system with the sole purpose of handling file I/O. The char- 
acteristics of the device on which the telegrams are stored 
are encapsulated within these two modules. 




A "A" CALLS "B' 
CYCLICALLY 


A “A" CALLS "3" 

aJ conditionally 


B 


'A*' USF.i SYSTEM SERVICE “B" 


SAl-0312 


I'igure 2-2 Module Structure Chart for Example 



Jit 
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TABLE 2-7 


MODULE DESCRIPTIONS FOR EXAMPLE 


MODULE 

GET_TELEGRAM 

GET_WORD 

GET_CHAR 
FILL BUFFER 


PURPOSE 

Collects words belonging to each 
telegram and prints them in a neat 
manner along with the chargeable 
word count . 

Collects characters into words and 
prints error messages denoting over- 
length word or physical record end 
of file. 

Returns the next character in the 
telegram file. 

Enters the next physical record 

from the drum into the character buffer. 
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REPRODUCIBILTTY of t 


PRIGINAL PAGE IS POuU 


/• bpuinntng of main subsystem preamble */_ 


ri •jni i‘i iiKuit 

i ransdiiot Inns 
collect ^ print; 
output 

teleeram, charge_count 
end; 


r yah 1 e teleKram; text ; 

charge count- integer ; 

for print; 

■subject to charge_count ^0 J 
word_cC)unt : inte ger; 
for print; 

■subject to word_count > charge_count ;■» 

word l aFray Hi ■ ■ l^j of char ; 

lor print; 

eof f lag: boolean ; 

for print 

('n^; /* end of main subsystem preamble •/ 

/* main routine to collect words and */ 

/* print telegram with chargeable word count*/ 

module gei_telegram; 

f ul fill s print; 

creates telegram. charge_ count using word; 

creates «ard_c..junt ; 

m odi f les word_count; 

uses eof_flag; 

accesse.s line_prititer; 

executes cyclically get_word: 

satisfies 

eof_flag or word_count = 0 

end : 


2 . 1 . 2 . 6 . 2. 1 


/* subroutine to collect characters into */ 

/• words •/ 

mo dule get word: 

fulfill.s collect; r \ 

executes cyclically i_o . get_ohar( a_char : char ; eof_f lag) ; 
creates word, eoi_flag; 

accesses line_printer /*prints error messages ♦/ 

end “ ~ 

end; /* end of main subsystem */ 


Figure 2-3 SSL Description for Example 
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/♦ beginntnff of i_o subsystem prearpble •/ 


Hubs ys tem i_o; ^ 

red uh'i.'inent 

Input character_file;^ 

transductions 


read ^ separate; ■ 

output a_char, eof_flag - 

end ; ^ ^ — 

/• parameterize record length */ 

c onstant record_length = integer 

type (!haracter_record = array 01 . . record_length^ of char : 

vari able character f ile : soquence of character^record;-.^ 

for read; 

buffer: character_record ; 

for separate; 
a_char;char ; 

tor separate; 

char_i'ndex; 1 record-length ; 

for separate; 
eof flaE: boolean ; 

~ for Separate*— 

end ; /* end of subsystem preamble */ 


/‘ subroutine to fetch next •/ 

/* character from file */ 

oiUr^ gr’l_char (a_rhar; eof_flag) ; 

ful fill s separate; •— 

executes conditional ly fill buffer: - — 

modifies char^index; ~ ' ^ — — 

t:rcates a_char using buffer 0char_inde>0 , eof_f 
crea tes character_file , char_index; ^ — 

satisfies eof_flag impl ies a_char = buffer [char index") 
end ; ^ 

/* .subroutine to fetch next physical */ "" "" 

/♦ record from character file */ 

module fni_buffer; 

I'ulf ills read ; * ^ 

nssumcs char_index = record_length 

arcer as disk; *" ~ ^ — - 

cr~eatbs" "bufier, eof_flag using character fileg , ; 

satisfies ^ q- :- ^ 

eof_flag implies buffer = character_f ile@ 
end L j 


end /♦ end of subsystem */ 
end; /• end of specification */ 


Figure 2-3 SSL Description for Example ( continued) 


2.2 SEMANTIC DESCRIPTION OF SSL 

Our semantic description of SSL is in terms of sets and 
soL I'unctions grouped into n-tuples. The initial construct is 
Lhc Vortex Correlation Tuple which forms the basis for definition 
of a single subsystem of the software structure. This tuple con- 
sists of a set of nodes, some of which have module names attach- 
ed. Virtual nodes do not represent program modules, but evoca- 
tions of entry nodes of separate subsystems. Modules are repre- 
sented by concrete nodes. Special types of concrete nodes, 
called entry nodes, are a distinctive characteristic of sub- 
systems other than the main subsystem and have special properties 
First, they must have attached module names, so they can be ref- 
erenced by other subsystems. Second, (as we shall see in the Re- 
quirements Graph) their predecessor may only be the root node of 
the subsystem which is not permitted an attached module name. 

Vertex Correlation Tuple 

X = (N,C,V,G,Z,M,mod) 


where 


= a finite set of labeled nodes 

= a subset of N called concrete nodes 

= a subset of N called virtual nodes; VAC = $ 

= a subset of C called entry nodes 

= a distinguished node called the root 

= a finite set of module names 
I : N ->■ M: a module name mapping function 

I If neC, then cardinality (mod (n)) = 0 or 1 . 

\ If neG, then mod (n) f entry nodes are required 
to have an attached module name. 

I If neV, then mod (n) f virtual nodes are required 
to have an attached module name. 

I If G ^ tben mod (Z) = the root nodes of sub- 
systems other than the main subsystem are not per- 


mitted to have attached module names 
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The module mapping function (mod) implies: 

(1) Not all concrete nodes have an associated module 
name . 

(2) Module names associated with virtual nodes are 
not necessarily unique; each evocation of an entry 
node is represented by a distinct virtual node. 

The nodes in x will be collected into a weakly-connected 
digraph based on a mapping of nodes to subsets of requirements. 
(For reasons of clarity and stand-alone interpretation, we are 
using "requirements" in the sense we used "transductions" in 
the previous part.) To accomplish this, the requirements are 
partially ordered by implication. If R is a set of require- 
ments, r^, rg eR, we write r^ (read "r^ is implied by r^"). 

For example, consider a line editor. The requirements are: 

edit, search_file, delete_line, add_line 

The implications between these requirements are as follows: 

(1) delete_line ^ edit 

(2) add_line edit 

(3) search_file £ edit 

(4) Search_file £ delete_line 

(5) search_file £ add_line 

(6) delete_line £ add_line, add_line £delete_line : 
i.e., {delete_line , add_line} is unordered. 

With nodes mapped onto subsets of a set of partially 
ordered requirements, it is possible to define the predecessor 
relationship between nodes by a function. The function (called 
simply the predecessor function) requires that in order 

for n^ to be a predecessor of where r^ is a certain require- 
ment attribute of n^ depending on r 2 • 
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The Requirements Graph 


where 


n = (x,R,B,req,pr) 


(4 )req ; N ->2 


( 5 ) pr:N-> 2 ' 


= A Vertex Correlation Tuple 

= a finite set of labeled requirements, parti- 
ally ordered by implication 

= a base set of R; if r^eB, then 
rgSR, r^ f such that 

= the requirements mapping set function; a sub- 
set of R is associated with each node 

req(Z) = B 

If n e N then req(n) f •I' 

= the predecessor set function 

pr(Z) =$; if n ^ Z then pr(n) f $ 

If n^epr(n2) then we define (n^jn^) to be adja- 
cent in a digraph sense 

If r2£req(n2), n^epr(n2) then there exists 
r^ereq(n^) such that r2 £ 

If n^,n2epr(n2) , r^ereq(n^), r2ereq(n2) then 
^ ^ 2 ’ ^2 ^ ^ 1 ' i.e., the requirement at- 
tributes if taken one each from the predecessors 
of a node are unordered 

If n^epr(n2) then n^eC; i,e., virtual nodes may 
not have successors 

If n^eV, n^eprCug), n2epr(n2) then n^ = Ug 
i.e,, virtual nodes have exactly one predecessor 

If n^eprCng), HgSV then req(n^) = reqCng); i.e., 
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virtual nodes have the same requirement attri- 
butes as their predecessor 

(h) If neG then pr(n) = {Z} 

In addition to modules at graphical nodes, the other 
resources available to a software system are environment objects 
and data objects. Data objects are created at one and only one 
point within the system for use elsewhere; environment objects 
arc not "created" but may be used or "accessed" at various point; 
within the structure. A further distinction is that data ob- 
jects, but not environment objects, have requirement attributes. 
The requirement attributes of data objects are not necessarily 
the same as those of the creating node. These attributes de- 
limit where within a structure a data object may be used. 

Object Distribution Graph 

A = (it, Q, E, cr, drq, acc) 


( 1 ) 7r = A Requirements Graph 

(2) Q = DUE a finite set of labeled data objects; 

DAL =4),' if deD then d is called a global data 

object; if deL then d is called a local data 

object 

(3) E = a finite set of labeled environment objects 

(<1) cr:C->2^ = object creation set function 

(a) If deD, decr(nj^), decr(n 2 ) then n^ = ng; i.e., 
an object is created at one and only one node 

(b) ir deD then decr(n) for some n: i.e., all data 
objects are created within the system 

(5) drq:D->-2^ = data requirements set function 

(6) acc;C'>^2 = environment access set function; eeacc(n) if 

ecE and e is accessed at concrete 
node n 
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Thus far, the constituents of a software structure that 
have been developed are; 

(1) Nodes with attached modules 

(2) Node interconnections based on requirements order- 
ing 

(3) Data objects created and environment objects 
accessed , 

In order to complete the interconnection graph, it is necessary 
to depict the utilization of data objects. A global data obj- 
ect is assigned requirement attributes via the drq function and 
these attributes are compared to those of potential user nodes. 

I r n is a concrete node then d, a data object, is available for 
use only if for each r^ereq(n) there exists rgCdrqCd) such that 
Tg or d is a member of the release set of n or an immediate 
successor of n. In effect, data object requirement attributes 
place an upper bound on the generality of modules permitted use 
as well as limit the object's scope to specific segments of the 
graph . 

Subsystem Structure Graph 

Z = (A, rel, av, use) 

where 


( 1 ) 

( 2 ) 


A = an Object Distribution Graph 

>Q 


^ and 


(3) 


rel : (N,,N)-^2'^ = release set function; 
if rel(n^,n 2 ) f then n^epr(n 2 ); i.e. , n 
must be adjacent in a digraph sense if n^ may re- 
lease objects to n 2 
,Q 


av ; N-+2 


availability set function: 


(a) 


If deD, neC, deav(n), r^ereq(n) then r ] 
for some r 2 edrq(d); i.e., each requirement 
attribute of a concrete node must be sub- 
sumed by at least one of the requirment 
attributes of the global data object. 


R^EOpyCrolLTTY^OFJHE 


J^/ 
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(b) If deL, n^eN, deav(n^) then either derel 

or derel(n 2 ,n^) ; i.e., local data 
objects may be shared only by pairs of nodes 
that are adjacent in a digraph sense. 

(c) If deav(n), neV then derel(n^^n) where 

pr(n) = {n^}; i.e., a data object available at 
a virtual node must have been released by its 
parent . 

(d) If derel(c,v) then deav(c) where ceC, deQ, 
i.e., concrete nodes may release to virtual 
nodes only those data objects which are ele- 
ments of the availability set of the concrete 
node. 

(4) use:N^2^ = usage set function; deuse(n) if deav(n) 
and d "is used" at n as determined by the 
designer . 

The definition of the System Structure Graph is the final 
step in describing the semantics of SSL. The ultimate goal is 
an automated version of SSL which will: 

• Permit partial system definition with con- 

sistency checking at the appropriate level 
of detail, and 

0 Participate in the design by supplying derived 

information and indicating the next logical steps 
in an incremental development. 

Accomplishing this will depend on discerning higher order rela- 
tionships among the functions describing SSL. This involves 
identifying theorems and algorithms that derive the set defined 
by one function through the sets defined by other functions. 

A subsequent section represents our efforts in this direction. 
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2.3 


OVERVIEW OF THE SSL TRANSLATOR 


In this section we give the formal software requirement 
Tor the translator, the functional design, and notes on detail- 
ed design. Significantly more detailed information exists on 
the functional design, including a description in the SSL lan- 
guage, than that presented here. The format and notation used 
for the functional design description in this report is more 
conventional , 

The notes on detailed design concentrate on the more 
critical semantic and structure analysis phase. Included are: 

• A method for determing the legitimacy of 
data/module interconnections 

• A method for ordering modules in a manner 
that facilitates module interconnection 
and recursive analysis 

0 A method for constructing a matrix over which 

module interconnection and recursive analysis 
can be performed 

0 Rules for determining which modules are poten- 

tially recursive. 

2.3.1 The Formal Software Requirement 

In our terminology, the software requirement is a de- 
tailed declaration of the actions to be performed by a single 
software package. It includes what is to be done as well as 
initial estimates of "when" and "how well" various actions are 
to be performed. The constituent parts of the software require- 
ment decomposition are: 

Direction - A general statement of the boundaries 
of the problem 

Input - Data or documents available to the soft- 


ware system or subsystem from external 
sources 
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Transductions - A list of processing steps to be per- 
formed, each of which translate a 
stimulus into a response 

Output - Data or documents produced by the soft- 

ware for external purposes 

Constraints - A list of capacities, design objectives, 

or resources to be observed 

Preconceptions - A list of specific design alternatives 

to be observed 

Implications - A binary relation existing between 

certain pairs of transductions, indi- 
cating which are substeps of others. 

Of the seven divisions, the constraints and preconceptions are 
optional. If all transductions are independent, the implica- 
tions may also be omitted. 

The level of detail required for the SRD is generally 
greater than could be expected of a casual user of data pro- 
cessing services. For this reason, it is expected that the SRD 
will be completed by an experienced computer specialist after 
reviewing the user requirments. Completing the SRD is the be- 
ginning step of functional design. 

Figure 2-4 depicts the SRD lor the SSL translator. 

There are three major segments within the transductions: pro- 

gram analysis, structure analysis, and report summarization. 

The implication relations between tranductions is represented 
in Figure 2-4 by indentation within the transduction division 
rather than within a separate implications division. 

The only system (or requirement) level input is the SSL 
source language. System output consists of eight items. In 
addition to the source listing, syntax and semantic errors, these 
consist of: 

JI/~- 
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Module concordance - An alphabetical list of all modules ;| 
for each module the following information is 
given; 1) modules it calls, 2) modules which 
call it, 3) variables referenced, 4) environmen- 
tal objects referenced, and 5) requirement at- 
tributes 

Variable concordance - An alphabetical list of all 
variables; for each variable the following 
information is given; 1) requirment attributes 
and 2) modules which reference it 

Requirement concordance - An alphabetical list of all 
requirment transductions and constraints; for 
each, the following information is given; 

1) modules to which attached as an attribute, 

2) variables to which attached as an attribute, 

3) (for transductions) the transductions immed- 
iately above and below it in a partially ordered 
sense 

Summary - A summarization of the number of modules, 
variables, errors, etc. by subsystem 

Index - A cross reference guide to facilitate access 
to parts of the SSL generated report 
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DIRECTION 


Implement an automated translator for Software Specification Language (SSL) 

INPUT 

SOURCE: A set of logically connected SSL statements. 

TRANSDUCTIONS 

TA_PROG_ANALYSIS : Analyze the SSL program 

TB_SYNTAX: Analyze the program syntax 

TC_TOKEN: Reduce the next lexical token 

TD_CARD : Read and print the next card image 

TC_SYN_ERR: Perform syntax error recovery procedures 

TC_TABLES ; Construct dynamic tables 

TD_REQ_ST: Process requirement statement 

TD_CONS_ST: Process constant statement 

TD_ful_ST:' Process fulfills statement 
TD_TYPB_ST: Process type statement 


TE RECORD: Process record and digital forms 



Figure 2-4. SRD for SSL Translator 


TF_ARRAYS : Process array forms 

TF_SUBRANGE : Process subrange forms 

TF_SCALARS ; Process scalar forms 
TF_BASIC: Process basis type forms 

TF_POINTER: Process pointer forms 

TE_FILE : Process file and sequence forms 

TF_ARRAYS, TF_SUBRANGE, TF_SCALARS, TF_BASIC, TF_PO INTER 

TD_VAR_ST: Process variable statement 

TE_FOR: Process for clause 

TE_POLISH: Analyze a polish string 

TE_RECORD, TE_FILE 

TD_MOD_ENT_ST : Process module and entry statements 

TF_BASIC 
TEJRELEASE 

TD_SUBSYS_ST : Process subsystem statement 

TD_EXEC_ST: Process executes statement 

TE_RELEASE : Process release form 

TF_BASIC 

TD__USES__ST : Process uses statement 

TE_DATA_LIST : Add items to data list 

TD_MOD_CR_ST ; Process modifies or creates statement 
TE_DATA_LIST 

TD_XMIT_RX_ST : Process transmit or receives statement 

TE_DATA_LIST 

TD__ASUM_SAT_ST : Process assumes and satisfies statement^^^ 

TE POLISH 


Figure 2-4. SRD for SSL Translator (continued) 




TA-STRUC^AMLYSIS ; Analyze the software decomposition structure 

TB ELEMENTS: Ascertain all elements are consistent within themselves 


TC_SUB_DEF 
TC_MOD_DEF 
TC VAR DEF 


Evaluate all subsystem definitions 
Evaluate all module definitions 
_ _ Evaluate all variable definitions 

TC_TYPE_DEF: Evaluate all type definitions 

TC_REQ__DEF: Evaluate all requirement definitions 

TB_SETS : Construct and evaluate all interelement relationships 

TC_REQ_VS_REQ : Ascertain requirement definitions are consistent 

TD_REQ_CON : Construct requirement concordance lists 

TE_MDR_MATRIX ; Construct a module/data/requirement matrix 
TE_NEXT_REQ: Find next alphabetically ordered requirement 

TE_MOD_ATT: Construct list of modules to which requirement 

attached 

TE_SUP_ATT: Construct list of superstep transductions 

TC_MOD_VS_REQ : Ascertain module hierachy consistent with requirements 

TD_MOD_VECT: Construct a module requirement vector 

TD_CLOS__VECT : Perform closure over a requirement vector 

TC_MOD_VS_DAT : Ascertain modules use data consistent with requirements 

TD_AD_VECT : Construct a variable availability vector 

TD_MOD_VECT , TD_CLOS_VECT 

TD_DAT_CON : Construct data concordance list 

TE_DAT_MATRIX : Construct data concordance list 

TE__NEXT_DAT : Find next alphabetically ordered variable 

TE_REFER: Construct list of modules reverencing 

dat a object 
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TC_MOD_VS_REL 
TC_MOD_VI_MOD 
TD ORDER 


Ascertain module release sets are consistent 
Ascertain module calling hierarchy consistent 
Order modules by forward paths 


TD_MATRIX: Construct D Matrix 

TD_RECURSIVE : Perform recursive analysis 

TE_POT_RECUR : Mark recursive modules 

TE LAT HEAD; Mark latch and head modules 


TD INV HIER: 


Construct inverse hierarchial list 


TE_INV_MOD: Find next inverse call module 

TC_REPORT_GEN ; Generate report 

TD_REQ_REPORT : Print requirement concordance 

TD_DAT_REPORT ; Print variable concordance 
TD_MOD_REPORT : Print module concordance 

TA _REPORT : Summaries and index report 

TB_SUMMARY : Print summary of software report 

TB_TOC; Print table of contents for report 

TC MOD_LIST; Print modules in alphabetical order 

TD_NAME_PAGE : Print a single name and page number 

TC_DAT_LIST; Print variables in alphabetical order 
TD_NAME_PAGE 

TC_REQ_LIST; Print requirements in alphabetical order 
TD NAME PAGE 


OUTPUT 

SOURCE_LI STING: A line printer listing of the original SSL source 

SYN_ERRORS ; SSL syntax error diagnostics interleaved with the j 
source listing M 

Figure 2-4. SRD for SSL Translator (continued) A 
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SEM_ERRORS ; A printed summary of all semantic incongruities 
HIER_LIST: A list (alphabetical) of all modules which includes modules 

referenced, inverse hierarchy, data referenced, environment 
objects referenced, and requirement attributes. 

DATA_LIST: A list (alphabetical) of all variables accompanied by the names 

of modules which use them and requirement attributes assigned. 

REQ_LIST: A list (alphabetical) of all requirements cross referenced with 

modules, variables, and other requirements 

SW_SUMMARY : A summarization of the software which includes counts for 

modules, variables, errors, etc. 

INDEX_LIST: A cross reference guide for facilitating access to parts of 

the SSL generated report 

IMPLICATIONS 

(Implications are represented by indentation within the transductions substation.) 
CONSTRAINTS 

LANGUAGE; ANSI FORTRAN IV will be used to implement the translator 

HOST_MACHINE : The translator will be written in a manner amenable to trans- 

portability; the host machines shall at least include the IBM 
S360/65 and Univac 1108. 


Figure 2-4. 3RD for SSL Translator (continued) 







2.3.2 


Functional Design Overview 


The module decomposition follows closely the requirement 
decomposition of Figure 2-4, There are three phases. The first 
phase analyzes the SSL source input and constructs a hierarchical 
file C:.mtaining all object attributes and interrelationships. 

The second phase analyzes the information within the hierarchi- 
cal file for semantic errors, then generates a report on the 
software organization. The third phase prints a summary and 
generates an index to the report. 

Figure 2-5 depicts a high level view of the software 
organization. The three phases depicted are executed once con- 
secutively to produce the report from the SSL source program. 

The block labeled "SSL Translator Main Program" is the control 
program. The actions performed by each of the phases is dis- 
cussed in the paragraphs below. 

The first phase (controlled by the block labeled "Syn- 
tax Analyzer" in Figure 2-5) is the source program analysis 
phase. Its function is to read the source program and construct 
the file used in subsequent phases. The purposes of the princi- 
pal blocks are as follows: 

• Syntax Analyzer - The subroutines of this block 
parse input source statements, emit syntax diag- 
nostics and pass the parse trees (polish notation) 
to the semantic analyzer 

• Lexical Analyzer - The subroutines of this block 
read and print the source statements; from the 
source statements, the tokens (numbers, reserved 
words, delimeters, and identifiers) are collected 
and returned to the syntax analyzer 

• Semantic Analyzer - The subroutines of this sec- 
tion collect the parse trees and, when one is 
sufficiently complete, passes it to lower level 
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SSL TRANSLATOR MAIN PROGRAM 


SYNTAX ANALYZER 


STRUCTURE ANALYZER 


POST ANALYSIS PHASE 


LEXICAL ANALYZER 


SEMANTIC 

ELEMENT 

SET 

SUMMARY 

INDEX 

ANALYZER 

ANALYZER 

ANALYZER 

GENERATOR 

GENERATOR 


MODULE 

STATE. 


VAR 

TYPE 1 

STATE. 

■ STATE. I 


MODULES REG'S. 


I SET 

CONSTRUCTION 


REPORT 

GENERATION 


RECORD 

FORMATTER 


MODULES VS. 

SUBSYSTEMS . . . 

VARIABLES VS 

MODULE 

VARIABLE 


REQUIREMENT 

REQUIREMENTS 

VS. MODULES 

MODULES 

CONCORDANCE 

CONCORDANCE 


CONCORDANCE 


Figure 2-5. Block Diagram for SSL Translator 






















subroutines; the lower level subroutines called 
by the semantic analyzer are differentiated by 
statement type and each constructs a specific part 
of the hierarchical file. 

The second phase (controlled by the block labeled 
"Structure Analyzer" in Figure 2-5) is where the software inter- 
connections are examined for consistency. Each element (sub- 
system, module, variable, etc. ) is examined first for internal 
or self-consistency. Self-consistency includes each element be- 
ing defined, referenced, and having all attributes assigned. 

A I' tor element analysis, set analysis takes place. Set analysis 
involves testing the consistency of all interelement references. 
Thi.s task is performed in two parts. The first part constructs 
the interelement relationships in the form of a set of boolean 
matrices. Semantic error analysis is carried out from the 
matrices and their representation is converted to a list struc- 
ture. This list structure is used in the second part of set 
analysis to generate the software structure report. 

The role of the second phase can be further clarified 
by examining the function of each of the blocks in Figure 2-5. 

• Structure Analyzer - Control routine for phase 2 

• Element Analyzer - On a subsystem by subsystem 
basis, the subroutines of this block examine the 
various elements that comprize the subsystem for 
intraelement consistency; the lower level sub- 

[ routines that the element analyzer calls are dif- 

ferentiated on the basis of element type. 

• Set Analyzer - Control routine for set analysis. 
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• Set Construction - The subroutines of this block 
construct a data base containing interelement de- 
pendencies, and alalyze the dependences for seman- 
tic errors; the lower level subroutines called by 
set construction are differentiated on the basis 
of element type pairs (modules vs. requirements, 
subsystems vs. modules, etc.). 

• Report Generation - The subroutines of this block 
generate the software structure report; the lower 
level subroutines called by report generation are 
differentiated on the basis of the various sections 
of the report (modules, variables, etc.). 

The third phase (controlled by the block labeled "Post- 
Analysis Phase" in Figure 2-5) summarizes and prints an index lor 
the report previously generated. The major blocks of this phase 
may be summarized as follows: 

• Post-Analysis Phase - Control routine lor the third 
phase . 

• Summary Generator - Prints a siimmary of the soft- 
ware structure such as the number of modules , 
number of variables, and number of errors per sub- 
system. 

9 Index Generator - The subroutines of this block 

generate a index list for each module, variable, 
etc., including which page of the source listing 
and concordance listings it occurred. 

• Record Formatter - Prints a single line of the inde? 
which includes a name with page numbers. 

2.3.3 Detailed Design Notes 

Phase 1 of the translator is a standard parser combined 
with data structure synthesis routines. Phase 3 is simply an 
output editor. The crucial subset is phase two in which the 
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interelement relations are analyzed semantically. The purpose 
or this section is to expound both algorithmically and theoreti- 
cally on some of these relationships. 

2. 3. 3.1 Assessing Data Availability 

Recall that requirement attributes are attached to both 
modules and data objects as a means of providing requirements 
traceability. A secondary effect of requirement attributes is 
that they limit the availability of data objects; i.e., a data 
object may not be used at a concrete node unless all the require- 
ments attributes of its module are equal to or implied by re- 
quirement attributes of the data object. Therefore, one might 
expect a close relationship between the requirement attribute 
functions (req, drq) and the availability function (av). This 
relationship is expounded below. 


P(d) - 
where : 


Let R = 
(P]^, V2> 




be a set of requirements . Let 




Let Q(n) =(q. 


^j = 


0 


0 


,Pj^) be a data object requirement vector 


if rj edrq(d) or r^ < r^ where r^^ e drq(d) 


otherwise . 

. ., q^^) be a node requirement vector where; 

if r . ereq(n) , n e C 

i3 


otherwise . 


Theorem 


For any n e C, d e av(n) if and only if Z q. = P(d) • Q(n) 
Proof (necessary) assume ne C and d e av(n). Then^ by definition 
of the av function, for any r^ £ req(n) there exists an in 
drq(d) such that rg^r^. So ”^^j ^ neq(n) =^3:^ £ r^^ for some 

L drq(d) => p^ = 1; . * . 

k 

>; q = P(d) * Q(n). 

i=l 

The sufficiency part of the proof is carried out similarly. 

END OF PROOF 
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Note that the theorem applies only to concrete nodes 
since virtual nodes, unlike concrete nodes, depend additionally 
on the release function (rel). 

2. 3. 3. 2 Assessing Consistency of Data Usage 


Data object usage at a module is dependent upon its 
availability at that module. However, the two sets are derived 
from different perspectives and require cross checking. Ano- 
malies should prompt the designer to re-think the requirement 
attributes assigned objects, a healthy exercist . 


Let's begin by recalling that a data object, d, is not 
eligible to be used at a module, n, unless d e av(n) . Let D = 
^dj^, dg , • . . , d^ } be the set of data objects within the 

system. For some node n, let U(n) = 
the usage vector, be a vector where 

i l if d^ e use(n), n e C wibere C is concrete node 

;i=l,2, . . . .,m 

0 otherwise. 


u. 


u. 


u 


m 


Let W(n) = j^w^, Wg , • • • . %J 
vector where 

/ 1 if d^ e av(n) 


, the candidate vector, be a 
neC;i=l, 2, . . .,m 


^ 0 otherwise . 

Given U(n) and W(n) the usage set assigned to node n is legiti- 
mate only if 

Uf = Uf . Wf ; i = 1, 2, . . . , m 

Furthermore, if the set is illegal, the culpable object is 
identified by the element of U(n) for which the above test fails. 


^ ,\-X . ^ 
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2. 3. 3. 3 Ordering Modules for Analysis 

The predecessor relation defined in SSL semantics only 
partially orders the nodes (modules). There exists more than 
one total order that adequately reflects the partially ordered 
properties of any nontrivial module set. It is necessary to 
select a (total) ordering algorithm in order to perform analysis 
In a deterministc manner. 

The algorithm preserves the natural partial order of the 
modules. Definition of the following terms are necessary: 

e A unique module called the root or entry module 

(of a subsystem) 

ord(m) The order number of module m; initially zero for 
all modules 

pr(m) The predecessor function for module m as defined 
in the SSL semantics; pr" (m) is the successor 
function 

n The set of modules 

#S The cardinality of the set S 

The algorithm is as follows : 

(1) Let S^ = e ; set ord (e) = 1 

(2) Let p = 1, k = 1 

(3) If m^ e Sj^ and there exists m^ e NO ^pr ^(mp)-Sj^^, 
then 

(a) For each m^ such that p < ord (m^) £ 
increase ord (m^) by 1 

(b) Define ord (m^) = p + 1, ^ ^"^q ) 

(c) Increase p and k each by 1 

(d) Return to step (3). 

(4) If p >1, decrease p by 1 and return to step (3); 
otherwise stop. 
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This algorithm assigns an order number to each module. Further- 
more, the order numbers increase monotonically along forward 
(non-recursive) calling paths. Figure 2-6 illustrates the order 
number assignments for an arbitrary block diagram. Note that 
more than one order assignment combination fulfills the criterion 
of increasing order numbers along forward paths . 

2. 3. 3. 4 Construction and Closure of Dependency Matrices 

A dependency matrix (or adjacency matrix) is an n x n 
boolean matrix where there are n modules. Rows and columns must 
be ordered equivalently to the order numbers acquired from the 
algorithm given above. The elements of the dependency matrix, 

D, are as follows: 

’ = true if module of order i references module of 
, order j 

ij 

= false otherwise 

Once constructed, the rows of D yield "called” lists and the 
columns "called by" lists. 

Closure of D - In the closure of the matrix D (denoted 

d"^) an element d^^j will be true if there exists a sequence in D, 

d. ,dd ,...,d., all of which are true, 
xp' pq ’ qr ’ sj ^ ^ 

One way of deriving D is by raising D to the n power. 
The algorithm given here is much more efficient. 


D : array |l . . n , 1 

i, j , k: integer ; 

for j = 1 to n do 
begin 


nj of boolean ; 


for i = 1 n ^ 

if D [i » j] and i j then 
for k = 1 n do 

D [i, k] = D [i, k] or D [j , k] 


end ; 
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2. 3.3.5 Recursive Analysis Using Dependency Matrices 

It has already been noted that "called" and "called by" 
lists are explicitly represented in D. What remains is the 
derivation of the recursive information required for the module 
concordance of the previous section. Specifically, the deter- 
mination of head modules, latch modules, and potentially recur- 
sive modules. (A latch module, in the context of recursive 
analysis, is one that makes a recursive call. A head module is 
one to which a recursive call is made). 

Theorem 

If d. . = true and j < i then 
ij — 

i is the order no. of a latch module and j is the order 
no. of a head module of a recursive subsystem. 


Proof 

Assume ord(m^) = i and ordCm^) 


Since d. . = true, 
3 


calls m 2 - If there exists a forward calling path from mg to 
then the call of mg by m^ is clearly recursive with m^ being 
the latch and rag being the head. So, assume there is no forward 
path from mg to m^ . If there does not exist a forward path from 
mg to m^ then the path (m^, mg) is a forward reference . This 
implies ord(m^) <j , contradicting the original assumption. 

End of Proof 

Figure 2-7 is the D matrix for the dependency chart of 
Figure 2-6. It illustrates that 4 (Module I) is a latch module 
and 2 (Module E) is a head module. 

Theorem 

If d^t = true and i = ord(m) then m is potentially 
recursive (i.e., there exists a path from m back to itself). 

Proof 

By definition, d+^ is true if there exists a sequence, 

d._, d , .. ., d, . , all of which are true. This implies the 

ir rs t 1 ^ 

existence of a reference path, m, m^, mg, . . . , m, thus m is 
potentially recursive. 

End of Proof 
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Figure 2-8 is the D matrix for the dependency chart of 
Figure 2-6. It illustrates that 2 and 4 (Modules E and I) are 
potentially recursive. 

Note that the existence of a recursive path does not 
necessarily prove that modules on the path are recursive. During 
execution, the recursive path may never be traversed. Note also 
that a recursive call made unconditionally by a latch module is 
a potential infinite loop. 

The techniques above were discussed in the context of the 
module concordance. A subset of the same methods would apply 
also to the data concordance and to the analysis of the require- 
ment transductions. 


• • 



3. DATA BASE VERIFIER SUBSYSTEM DESIGN 


As a result of the study and analysis conducted under 
SOW task Phase A, item 3, we performed a high level design 
(i.e., software development through the requirements and func- 
tional specification stages) of a data base verifier subsystem 
(DBVS). The functions of this data base verifier subsystem are 
analysis of the Data Manipulation Language (DML) commands 
within a FORTRAN source deck ^collection of pertinent descrip- 
tions of the stored data base as viewed by the program(s), and 
printing of the subschema information in a user oriented for- 
mat. The accomplishment of these functions was the goal of 
each step in the DBVS software design. 

At the requirements stage of the development of the 
DBVS, we produced a Subsystem Software Requirements Document 
(SSRD). This document was written in accordance with the 
requirements methodology that we recommended as a result of 
analysis performed during this contract period (cf. Part I, 
subsection 2.1 of this report). Subsection 3.3 contains the 
SSRD which formed the basis of the functional design of the 
DBVS. For the specification stage, we used the Software Speci- 
fication Language (SSL) that was designed under this contract 
and which is explained in Part I, subsection 2.2 and Part II, 
.section 2 of this final report and in the special report, 

"SSL-A Software Specification Language.” 

A general description of the two main phases of the 
data base verifier, DML Statement Processing and Subschema 
Information Processing, are presented in subsections 3.1 and 
3.2. These subsections are outlined in Table 3-1. 
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TABLE 3-1, DBVS Description Outline 

Data Base Verifier Subsystem 

1.1 DML Command Processing 

1.1.1 DML Statement Recognition 

1.1.2 DML Statement Parsing 

1.1.3 DML Statement Components Storage 

1.2 Subschema Information Processing 

1.2.1 Subschema, realm, set, record, 
privacy, or error information 
retrieval 

1.2.2 Subschema, realm, set, record, 
privacy, or error information 
tabulation 

1.2.3 Summary Reporting 

1.2. 3.1 Subschema, realm, set, 
record, privacy, or 
error information printing 
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3.1 DML STATEMENT PROCESSING 

As each source statement is read, the first label 
(after the statement number field) of a non-comment statement 
is isolated by the DBVS using the information in Table 3-2. 
ir this label is succeeded by a left parenthesis, the DBVS com- 
pare.s this label with the keywords contained in the FORTRAN 
DML Command Table (cf. Table 3-2). When a match is found, the 
label is entered into the keyword sequence, and parsing of 
(,ho statement continues. (During parsing of the DML statements, 
the identified components of each clause or statement, i.e., 
the keywords, identifiers, or list items, are placed in three 
sequences . The sequence types were chosen because this type 
may vary dynamically in length in response to the variance of 
the number of keywords, identifiers, and list items within a 
DML statement). 

Within each DML clause, identifiers (which occur to the 
right hand side of the equal sign) must be isolated and entered 
into the identifier sequence. These identifiers could contain 
CODASYL keywords as shown in Table 3- 4 or one of the items 
(some of which contain keywords) in Table 3-5. 

Some DML statements such as FETCH, MODIFY, etc. allow 
specification of list items which must be isolated and entered 
into the list item sequence. According to CODASYL, the items 
fall into the two categories described in Table 3-6. 

The processing of DML statements including the con- 
sl'.ructlon of the keyword, identifier, or list item sequences 
continues in the manner described above until the entire state- 
ment has been parsed. Then the appropriate module is evoked 
according to the DML statement and its associated subschema 
information. 
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TABLE 3-3. FORTRAN DML COMMAND TABLE 


1. 

FETCH 

9. 

ORDER 

2. 

FIND 

o 

1 — t 

INVOKE 

3. 

GET 

11. 

READY 

4. 

STORE 

12. 

FINISH 

5. 

MODIFY 

CO 

ACCEPT 

6. 

ERASE 

14. 

USE 

7. 

CONNECT 

15. 

PRIVACY 

8. 

DISCONNECT 

16. 

QUIT 


TABLE 3-4. ALLOWABLE KEYWORDS WITHIN DML STATEMENTS 


1. 

SUBSCHEMA 

14. 

DUPLICATE 

27. 

INSERT 

2. 

SCHEMA 

15. 

ANY 

28. 

REMOVE 

3. 

ALL 

16. 

OFFSET 

29. 

STORE 

4. 

SET 

17. 

FIRST 

30. 

MODIFY 

5. 

REALM 

18. 

LAST 

31. 

FIND 

6. 

UPDATE 

19. 

NEXT 

32. 

GET 

7. 

RETRIEVAL 

20. 

PRIOR 

33. 

ERASE 

8. 

EXCLUSIVE 

21. 

CURRENT 

34. 

FETCH 

9. 

PROTECTED 

22. 

OWNER 

35. 

ORDER 

10. 

CONCURRENT 

23. 

RSE 

36. 

CONNECT 

11. 

ERROR 

24. 

USING 

37. 

DISCONNECT 

12. 

RECORD 

25. 

DISPLAY 

38. 

OTHER 

CO 

KEY 

26. 

PRIVACY 

39. 

STATUS 








TABLE 3-5. IDENTIFIER SEQUENCE ELEMENTS 


NOTE; These CODASYL definitions are predicated on the working 
document, "FORTREV,” of the ANS committee for the proposed 
revised FORTRAN, (X3.9). This document was printed in the 
March 1976 issue of SIGPLAN Notices under the title, "Draft 
Proposed ANS FORTRAN." 

• Character constant - is an apostrophe followed by 
a non-empty string of characters followed by an 
apostrophe. 

• Character expression - is used to express a charac- 
ter string consisting of a character primary alone 
or concatenated with other character primaries. A 
character primary may be a character constant, sym- 
bolic name of a character constant, character vari- 
able reference, character array element reference, 
character substring reference, character function 
reference, or character expression enclosed in paren- 
theses (cf. FORTREV 75-09-26, Section 4). 

• Character variable - FORTRAN variable of type 
character. 

• Data base key - Integer variable- (FORTREV 's 
definition of variable excludes array elements.) 

• Data base name - record name, set name, realm name, 
or character expression. (The first 3 are names in 
the subschema being used.) 

• Data base names - data base name. 

• Error phrase - contains keyword error and either 
statement number or subroutine (with arguments if 
applicable) name. 

• Retain - contains keyword RETAINING and either 

1) the keyword RECORD, REALM, SET or 2) keyword SET 
and appropriate data base names, or contains keywords 
RETAINING and MULTIPLE. 
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• Record selection expression - The various record 
selection expressions are given in Table 3-12 under 
the explanation of the FIND statement, 

• Statement number - consists of one to five digits 

• Subroutine name - consists of one to six letters or 
digits, the first of which must be a letter. 

• Usage - one of each of the following groups of 
keywords: 1) PROTECTED, EXCLUSIVE, CONCURRENT 
2) RETRIEVAL, UPDATE. 
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TABLE 3-6. LIST ITEM SEQUENCE ELEMENTS 

• Input list item which must be one of the following 
variable name, array element name, character sub- 
string name, array name, or array block item (cf. 
EORTREV 12.8.2.1) . 

• Implied-DO list item consisting of one of the 
following: a variable name, an array element name, 
a character substring name, an array name, or an 
array block item (cf. EORTREV 12.8.2.3), 
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SUBSCHEMA INFORMATION PROCESSING 


After the identifier, keyword, and list item 
sequences have been constructed, the various components 
of the DML statement containinp" subschema, REALM, SET, 
record, privacy, and error information must be extracted 
from these sequences. This information is then appropri- 
ately entered into one of the following tables: subschema, 
realm, set, record, or error status. The record description 
for each of these tables is given in Tables 3-7 through 
3-1.1, respectively. These record description tables contain 
specific information about the subschema which can be col- 
lected from the DML statements. Moreover, the printing of 
these tables in a highly readable format v;ill provide the 
user with different descriptions of the data base components 
which were established by the DML statements. With these 
labels, the user can cross reference the information and 
thereby determine the consistency of the data base descrip- 
tions within the bounds of the applications program. 

3.3 FUNCTIONAL REQUIREMENTS FOR THE DBVS 

As stated previously in Part I of this report, the 
specifications for the GODASYL DML are not in final form. 

The pertinent section of the CQDASYL FORTRAN Data Base Fac- 
ility Journal of Development (November 25, 1975), written by 
the Data Base Manipulation Language Committee,, was presented in 
the January 1976 monthly progress repott in Appendix A. It 
should be used as a reference for understanding the subsystem 
software requirements document subsequently presented in 
Figure 3->l. 


REPBOi^UCIBILffY OF THE 

origmal page is poor 
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TABLE 3-7. 


SUBSCHEMA TAEtLE RECORD DESCRIPTION 


Item Name 
Subschema Name 

Schema Name 

Privacy Key (assoc, with 
INVOKE or PRIVACY state- 
ment ) 

DML Command Indicator 


Indicates reference by 
one of the following 
DML commands: 

INVOKE 

PRIVACY 

Line Number 


Indicates line number of 
DML command in listing 


Data Type 

(cf. FORTREV, 
Section 4.8.1) 

(cf. FORTREV, 
Section 4.8.1) 

(cf. FORTREV, 
Section 4.0.1) 


Integer constant 
Integer data 


Integer constant 
Integer data 


j;/ 


3-10 


TABLE 3-8. REALM TABLE RECORD DESCRIPTION 


Item Name 
Realm Name 


Set Names 


(' Usage indicator 


Indicates one item from 
each of the following 
groups : 

1. PROTECTED, EXCLUSIVE, 
CONCURRENT 

2. RETRIEVAL, UPDATE 

Statement number or subroutine 
name for error handling 

Record Name 


Subschema name 


Privacy Key (assoc, with 
PRIVACY statement ) 

DML Command 
Indicator 

Indicates reference by 
one of the following 
DML commands : 

READY, FINISH, FIND, 
FETCH, OR PRIVACY 

Line Number 


Indicates line number of 
DML command in listing 


Data Type 

Integer variable 
Hollerith data 

Integer variables 
Hollerith data 

Integer constant 
Integer data 


Integer variable 
Hollerith data 

Integer variables 
Hollerith data 

(cf. FORTREV, 
Section 4.8.1) 

(cf. FORTREV, 
Section 6.2) 

Integer constant 
Integer data 


Integer constant 
Integer data 
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TABLE 3-9. SET TABLE RECORD DESCRIPTION 


Item Name 


Data Type 


Set Name 


Integer variable 
Hollerith data 


Record Names 


Integer variable 
Hollerith data 


Modification Indicator Integer constant 

Integer data 

Indicates that set rela- 
tionship has been changed 
within the program. 


Privacy Key (assoc, with 
PRIVACY St at ement ) 


(cf. EORTREV, 
Section 6.2) 


DML Command Integer constant 

Indicator Integer data 

Indicates reference by 
one of the following 
DML commands ; 


CONNECT, DISCONNECT, MODIEY, 
FIND, FETCH, ERASE, or PRIVACY 


Statement Number or 
Subroutine Name for 
Error Handling 


Integer variable 
Hollerith data 


Record Delete Indicator 


Subschema Name 


Integer constant 
Integer data 

Integer variable 
Hollerith data 


Line Number Integer constant 

Integer data 

Indicates line number of 
DML command in listing. 
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TABLE 3-10. RECORD TABLE RECORD DESCRIPTION 


Item Name 


Data Type 


Record Name 


Integer variable 
Hollerith data 


Set Name 


Integer variables 
Hollerith data - 


Realm Name 


Integer variables 
Hollerith data 


Subschema Name 


(cf. FORTREV, 
Section 4.8.1) 


Modification Indicator Integer constant 

Integer data 

Indicates that set 
relationship has been 
changed within the 
program. 

Statement Number Integer variables 

or Subroutine Name Hollerith data , 

Data Base Key Name Integer variables 

Integer data 


Data Item Names 


Integer variables 
Integer data 


Privacy Key (assoc, with (cf. FORTREV, 

PRIVACY statem.ent) Section 6.2) 

DML Command Integer constant 

Indicator Integer data 

Indicates reference by 
one of the following 
DML commands : 

FIND, GET, FETCH, STORE, 

MODIFY, ERASE, CONNECT, 

DISCONNECT, or PRIVACY 


REPRODUCIBILITY OF THE 
ORIGINAL PAGE IS POOR 
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TABLE 3-10. (Continued) 


Item Name 


Line Number 


Indicates line number of 
DML command in listing 

DML Statement Indicator' Integer constant 

Integer data 

Indicates privacy access 
by one of the following 
DML commands : 

INSERT, REMOVE, STORE, 

MODIFY, FIND, GET, 

FETCH, or ERASE 

Record Delete Indicator Integer constant 

Integer data 


Data Type 

Integer constant 
Integer data 


Indicates PERMANENT, 
SELECTIVE, or ALL 
record delete 
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TABLE 3-11. ERROR STATUS TABLE 
RECORD DESCRIPTION 


Item Name 
Procedure Name 

ALL indicator 

OTHER indicator 

STATUS indicator 


Data Typ e 

Integer variable 
Hollerith data 

Integer variable 
Hollerith data 

Integer variable 
Integer data 

Integer variable 
Integer data 


JI/ 


Problem ‘Statement : 


Design a data base verifier subsystem that analyzes 
FORTRAN Data Manipulation Language (DML) statements 
for the purpose of ensuring a consistent and valid 
data base evocation by the program. Print the results 
of this analysis in a form easily interpretable by the 
user. 

SYSTEM SOFTWARE REQUIREMENTS DOCUMENT 
Direction 


Design a data base verifier subsystem that analyzes all 
FORTRAN DML statements and organizes the subschema, realm, 
set, record, privacy, and error information contained 
within the DML statements into appropriate output for the 
user . 


Input 

LINE_BUFFER: FORTRAN DML source card 

Transductions 

INITIALIZE__SYSTEM ; Initialize DML command, character, 

and keyword tables, line number 
counter, etc. 


CHECK_DML_COMMAND : Check first keyword for a match in 

the DML command (Table 3-3) 

CHECK_DML_KEYWORD : Check keyword for a match in the 

keyword table (Table 3-4) 

BUILD_KEYWORD_SEQ : Build keyword sequence for each DML 

statement 

BUILD_IDENTIFIER_SEQ : Build identifier sequence for 

each statement 


Figure 3-1. Subsystem Software Requirement Document for 
DBVS 
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BUILD_LIST_ITEM_SEQ; Build list item sequence for each 

statement 

BUILD_DML_TABLE : Construct DML command table 

BUILD_KEYWORD_TABLE ; Construct keyword table 
READ_LINE: Read a line of source code 

EVOKE_MODULE : Evoke appropriate module after processing 

each DML statement or QUIT command. 


SUBSCHEMA_INFO : Subschema, realm, set, record, privacy, 

and error handling information in tabu- 
lar form 

Constraints 

Input ; The source code must be written in CODASYL 
extended FORTRAN which contains DML state- 
ments for program/data base interaction. The 
acceptable input formats are listed in Table 
3-12 . 

Implications 

BUILD_DML__TABLE C. CHECK_DML_COMMAND 

BUILD_KEYWORD_TABLE O CHECK_DML_KEYWORD 


READ LINE 


CHECK DML COMMAND 


READ LINE 


CHECK DML KEYWORD 


READ LINE CT BUILD KEYWORD FILE 


BBPRODUCIBILrrY OF Tii; 
ORIGINAL PAGE IS POQB 


Figure 3-1. (Continued) 
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TABLE 3-12. INPUT FORMATS 


1 . 

2 . 

3. 

4. 

5. 

6 . 

7. 


8 . 

9. 

10 . 


INVOKE(SUBSCHEMA=<char const >*, SCHEMA=<char const>* 
{/PRIVACY = <char const> *} ) 

READY ({ ALL ( {SET = <db names>*} [ {REALM = <db names>*}}, 
<usage>* [ , <error>+] ) 

FINISH({ALLl {SET = <db names>*} | {REALM = <db names>*}} 

[ , <error*>] ) 

CONNECT ( [RECORD = <db name>* , ] {ALL | SET =<db names>*}}, 

[ , <error>*] ) 

D I SCONNECTC [RECORD =<db name>*,]{ALL | {SET =<db names>*>}, 
[, <error> *] ) 

ACCEPT (CURRENCY =<db key> [ , <currency type> ][,<error>]) 
<currency type> ::={ {RECORD | SET}=<db name> | RUNUNIT | 
REALM=<db name> 
or 

ACCEPT(REALM NAME=<char var> [ , <name type>] [ , <error>] ) 
<name type> ::={ {RECORD | SET} =<db name>}| RUNUNIT | {KEY= 
<db key>) 

FIND( {<rse>|{RSE=<char exp>*} } [ , <retain>*] [,<error>*]) 

<rse> : : =<rse 1> | <rse 2> | <rse 3> | <rse 4> | <rse 5> | 

<rse 6> I <rse 7> 

<rse !>;:= KEY =<db key> [ , RECORD=<db name>] 

<rse 2> ; :={DUPLICATE| ANY} ,RECORD=<db name> 

<rse 3>:: DUPLICATE , SET=<db name> , USING=<id llst> 

<rse 4> : : =<posit> [ , RECORD=<db name>] 

[, {realm! SET}=<db name>] 

<posit>: :={OFFSET=<int exp> } j FIRST | LAST | NEXT | PRIOR 
<rse 5> : :=CURRENT[ ,RECORD=<db name>] [ {REALM | SET} = 

<db name>] 

<rse 6> ; :=OWNER,SET=<db name> 

<rse 7> : : =RECORD=<db name> , [CURRENT] SET=<db name> 
[,USING=<id list>] 

GET ( [RECORD=<db name> ] [^error> ] ) [ <item list>] 

FETCH( { <rse> | .{RSE=<char exp>*} } [ , <retain>*] [ , <error>*] ) 
[<item list>*] 

STORE (RECORD=<db name>* [ , <retain>*] [ , <error>*] ) 


* Meta symbols are explained in Table 3-13. 


Jlr 
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TABLE 3-12. (Continued) 


MODIFY( [RECORD=<db name>*] 

( [ , ALL I {SET=<db names>*}] [,ONLY] [,<error>*]) 

[<id list>*] ) 

ERASE ( [RECORD=<db name>* , ] [ <member type>] 

I , MEMBERS=<db names>*] [ , SET=<db names>*] 

[ , <error>*] ) 

<member type> : : = PERMANENT 1 SELECTIVE | ALL 

PRIVACY (SUBSCHEMA =<char con>* [, DISPLAY] , <priv key>*) 
<priv key> : : =PRIVACY={ <char exp> | <priv key proc> ) 

<priv key proc> : : = FORTRAN subroutine name 

PRIVACY [ (SUBSCHEMA=<name>* , ] REALM=<db name>* 

,<usage mode>*,<priv key>*) 

<usage mode> : := 

[ , {PROTECTED I EXCLUSIVE}] [ , RETRIEVAL | UPDATE] 

PRIVACY ( [SUBSCHEMA=< char con>* , ] RECORD=<db names>* 

[ , <dml stmt>*] ,<priv key>*) 

<dml stmt>::= 

{ INSERT I REMOVE | STORE | <erase> j MODIFY ] FIND | GET 
FETCH} 

<erase> : =ERASE {PERMANENT | SELECTIVE | ALL} 

PRIVACY({SUBSCHEMA=<char con>* , ] SET=<db names>* 

[,<dml type>+] , <priv key>* 

<dml type>: :=0RDER] CONNECT [DISCONNECT | <erase> | FIND | 
FETCH 

<erase>::= ERASE {PERMANENT | SELECTIVE | ALL} 

PRIVACY ( [SUBSCHEMA=<char con>*,]<item dml>,<priv key>*) 
[<id list>*] 

<item dml>::=MODIFY{GET|FETCH} 


* Meta symbols are explained in Table 3-13. 


JI/ 
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TABLE 3-12. (Continued) 


14 . USE(PROCEDURE=<identif ier>* [ , {ALL | OTHER | (STATUS= 

<status list>*}}] 

15. ORDER( {SET=<db name>* }[, LOCALLY] {, <sort speO ...}[, <error>] ; 

<sort speO: ; = {ASCENDING I DESCENDING}=( RECORD I KEY I <sort 
f ield> . . . ) 

<sort iield> : ; = ITEM=<id 1‘i‘st > | KEY=<db names > | RE CORD= 

<db names> 


* Meta symbols are explained in Table 3-13. 

JI/ 
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TABLE 3-13. META-SYMBOL MEANINGS 


Meta-Symbols 
<char var> 
<char const> 

<char exp> 


<db key> 
<db name> 

<db names > 
<error > 


<id spec> 


Meaning 

character variable - FORTREV variable 
of type character 

character constant - is an apostrophe 
followed by a non-empty string of 
characters followed by an apostrophe 
character expression - is used to 
express a character string consisting 
of a character primary alone or concate- 
nated with other character primaries. 

A character primary may be a character 
constant , symbolic name of a character 
constant, character variable reference, 
character array element reference, 
character substring reference, charac- 
ter function reference, or character 
expression enclosed in parentheses. 

(See FORTREV 75-09-26, Section 4) 

data base key - integer variable 
( FORTREV 's definition of variable ex- 
cludes array elements) 

data base name - record name, set name, 
realm name, or character expression. 

(The first 3 are names in the subschema 
being used) 

data base names - data base name 

error phrase - contains keyword ERROR 
and either statement number or sub- 
routine (with arguments if applicable) 
name 

item specification - input list item 
which must be one of the following: 
variable name, array element name, 
character substring name, array name, 
or array block item (See FORTREV 
12 . 8 . 2 . 1 ) 
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TABLE 3-13. (Continued) 


Meta-Symbols 


Meaninf 


< identif ier> 


<id list> 


<item speo 


<item list> 


<priv key proo 


identifier - item specification 

identifier list - item specif ication(s) 

identifier specification - item speci- 
fication or implied-DO lists consis- 
ting of one of the following: a vari- 
able name, an array clement name, a 
character substring name, an array 
name or an array block item (12.8.2.3) 

item list - identifier specification 

subroutine name - consists of one to 
six letters or digits, the first of 
which must be a letter 


<retain> 


retain - contaim? keyword RETAINING and 
either 1) the keyword RECORD, REALM, 

SET OR 2) keyword SET and appropriate 
data base names; or contains keywoi’ds 
RETAINING and MULTIPLE 


<usage> 


usage - one of each of the following 
groups of keywords; 1) PROTECTED, 
EXCLUSIVE, CONCURRENT 2) RETRIEVAL, 
UPDATE 


<rse> 

(See Table 3-13 
number 7 input 
format ) 


record selection expressions - are used 
to specify criteria whereby the data 
base management system is to select a 
record in the data base. The various 
record-selection expressions are used 
as follows: 


Format 1 - direct access 
Format 2 - calculate mode access 
Format 3 - set search access 
Format 4 - positional access 
Format 5 - currency indicator access 
Format 6 - set owner access 
Format 7 - set occurrence selection 
rules access 


REPRODUCIBILITY OP TIF; 
OBMNAL PAGE IS 
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3.4 PUNCTIONAL SPECIFICATIONS FOR THE DBVS 

To facilitate the understanding of the DBVS functional 
specifications, the following documents should be used as 
references; 

• the portion of the "CODASYL’ FORTRAN Data Base 
Facility Journal of Development" (November 25, 1975' 
which was printed in Appendix A of the January 
1976 monthly progress report 

• the special report, "SSL-A Software Specification 
Language," which was prepared for this contract 

• the"draft proposed ANS FORTRAN, BSR X3.9, X3J3/76" 
which appeared in the March 1976 issue of SIGPLAN 
Notices. Any references to FORTREV appearing in 
the specifications are synonymous with those of 
the aforementioned ANS FORTRAN document. 

In the special report on SSL, explicit descriptions of the 
preamble components as well as subsystem and module descrip- 
tions for designing a software system are presented. A simple 
outline of this document (Table 3-14) will serve as a guide to 
understanding the SSL description of the data base verifier. 

In accordance with the SSL report, the subsystem preamble will 
be presented first (Figure 3-2) and then the module descrip- 
tions (Figures 3-3 through 3-10) . To accompany these specifi- 
cations, a module structure chart lor the DBVS (cf. Figure 
3-11) and a table containing a summary of the module descrip- 
tions (cf . Table 3-15) are given. 


TABLE 3-14. OUTLINE OF SSL COMPONENTS 


I. Preamble Description 

1. Requirement Declaration 

a. Input and Output Parts 

b. Transduction Parts 

c. Constraint Declarations 

2. Data Type and Variable Declarations 

a. Simple Types 

b. Structured Types 

c. Pointer Types 

3. Constant Declarations 

II. Module Description 

1. Module Statement 

2. Assumes and Satisfies Statements 

3. Fulfills Statement 

4. Accesses Statement 

5. Receives and Transmits Statements 

6. Creates, Modifies, and Uses Statements 

7. Execute Statement 

III. Subsystem Description 

1. Subsystem Preamble 

2. Module Description 



/♦preamble for DBVS subsystem*/ 

Requirement 

Input line_buffer; /♦I’ORTRAN dml source card*/ 
Transductions 

initialize_system; /*initialize dml command, char- 
acter, and keyword tables, line number 
counter,*) 

check_dml_command ; /*check first keyword for a 

match in the dml command table (Table 3-3) 
including terminate keyword quit*/ 

check dml_keyword; /*check keyword for a match 
in the keyword table (Table 3-4)*/ 
build_keyword_seq; /*build keyword sequence for 
each dml statement*/ 

build_identif ier_seq ; /*build identifier sequence 
for each statement*/ ! 

build_list_item_seq; /*build list item sequence ^ 

for each statement*/ 

build_dml_table ^ check_dml_command; /*construct 
dml command table*/ 

build__keyword__table ^ check__dml__keyword; 

/*construct keyword table*/ 
read_lin,e i^ check_dml_command, check__dml_ 
keyword, build_keyword_seq; /*read a line 
of source code*/ I 

evoke^module; /*evoke appropriate module after 

IDrocessing each dml statement or quit j 

command*/ j 


Figure 3-2, DBYS Subsystem Preamble 



save_subschema_inf o; /*save subschema, schema or 
privacy key names, and the dml command 
indicator in subschema table (Table 3-7)*/ 

save_realm_inf o ; /*store set or realm information 

and usage information in realm table (Table 
3-8 ) + j 

save__set_info >/.*store record (if specified) and 
set information in record and set tables, 
(Table 3-9 and 3-10 , respect ively ) 
save_record_inf o; /*store record name information, 
and if specified, item dml, record items, and 
privacy key information for record in record 
table (Table 3-l0)and pertinent record infor- 
mation in set table (Table 3-9)*/ 
save_subschema-privacy save_subschema_inf o; 

/*store subschema name and privacy key infor- 
mation for subschema in subschema table*/ 

save_realm_privacy ^ save_realm_info ; 

/*store realm name, subschema name (if 
specified), usage indicator, and privacy 
key information in realm table*/ 
save_set_privacy save_set__info ; /*store set 

name, subschema name (if specified) dml 
type indicator, and privacy key information 
for set in set table (dml type indicator 
reflects one of the following commands; order, 
connect, disconnect, find, fetch, permanent, 
selective, or all)*/ 


Figure 3-2. (Continued) 
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save_record_privacy save_record_info ; /*store 
record name and if specified, subschema name, 
dml statement (indicating insert, remove, 
store, erase (permanent, selective, all), 
modify, find, get, fetch) and privacy key 
information for record in record table*/ 
save_item_privacy iji save_record_inf o ; /*store 
item dml (modify, get, fetch) and privacy key 
information and if specified, subschema name 
and item names in record table*/ 
save_error_table_inf o ; /*store error information 
in error table (Table 3-11 )*/ 
print_tables ; /*i’ead and write information from 
subschema, realm, set, record, and error 
tables and write to printer*/ 

Outp ut subschema_info ; /*subschema, realm, set, 

record, privacy, and error handling information 
in tabular form*/ 

end ; 

/* beginning of data description within the preamble*/ 

variable dml_intrinsic ; array . 5 J ^ text ; /* 

contains current dml command lor check_dml_ 
command*/ 

for check_dml_command , check_dml__keyword, build_ 
keyword_seq, build_identif ier_seq , build_list 
item_seq, evoke_module , read_line, save_sub- 
schema_info, save_subschema_privacy , save_ 
realm_ info, save_realm_privacy , save_set_ 
info, save_set_privacy , save__record_inlo , 
save_record_privacy , save_item__privacy ; 


Figure 3-2, (Continued) 
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variable keyword_table : array [1..39, l-.bj of 

text ; /*Table 3-4( allowable keywords within dml 
statements)*/ 

for build_keyword_table, check_dml_command, 

check_dml_keyword, biiild_keyword_seq , build_ 
identif ier_seq j build__list_item_seq, evoke_ 
module, read_line, save_subschema_info , 
save_subschema_privacy , save_realm_inf o , 
save_realm_j)rivacy , save_set_info , save_set_ 
privacy, save_record_inf o , save_record_pri- 
vacy , save_item_privacy , save_error_table_ 
info, build_dml_table , initialize_ system; 
variable list item: array [1..3] of text ; /* con- 
tains user specified list item*/ 

for check_dml_command, check_dml_keyword , build_ 
keyword_seq, build_identif ier_seq, build_ 
list_item_seq , evoke_module , read_line, 
save_record_info , save__record_privacy , save_ 
item_privacy ; 

variable identifier; array Ci..i of text;/* con- 
tains user specified identifier*/ 
for check__dml_command, check__dml_keyword, build_ 
keyword_seq, build_ident if ier_seq , build_ 
list_item_seq , evoke_raodule , read__line , 
save_subschema info, save__subschema_privacy , 
save_realm_inf o , save_realm_privacy , save_ 
set__info, save_set_privacy , save_record_info , 
save_record_privacy , save_item_privacy , save__ 
error_table_inf o ; 
type ident seq= sequence of text 

ident : array [1..3] of text /* identifier name*/ 


Figure 3-2. (Continued) 
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variable dml_coramand_table : array Ql , . 16 , 1..^ of 
text ; /^contains commands of Table 3-3*/ 
for build_dml_table , check_dml_command , check__dml 
keyword, build_keyword_seq , build_identif ier_ 
seq, build_list_item_seq , evoke_module , read_ 
line, initialize_system, build_keyword_ 
table; 

variable keyword: array Ql . , ^ of text ; /* contains 
user specified keyword*/ 

for check_dml_command , check_dml_keyword , build_ 
keyword_seq , build_ident if ier_seq , build_ 
list-item_seq, evoke_module , read_line, save_ 
subschema_inf o , save_subschema_privacy , save_i 
realm_info, save_realm_privacy , save_set_ 
info, save_set_privacy , save_record_privacy , 
save_item_privacy , save_error_table_info , 
save_record_inf o ; 

type line_buffr = array [l . .7^ oj[ cha r ; 

/*ref lection of program card*/ 
variable line_buffer: line_buf fr ; /*contains current 
source statement being analyzed*/ 
for read_line, check_dml_command, check_dml_ 

keyword, build_keyword_seq , build_identif ier__ 
seq, build_list_item__seq, evoke_module ; 
variable char_table; array Ql. .4Q) ^ char ; /* 

A..Z, 0..9 , blank, =, +, *, /, (, ), ,, ., ;, 

:,$*/: 

for check_dml_command, check_dml_keyword, build_ 
keyword_seq, build_identif ier_seq , build_ 
list_item_seq, evoke_module , read_line, 
initialize_system, build_dml_t able , build_ 
key wor d_t able; 


Figure 3-2. (Continued) 
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variable identif ier_seq : ident__seq; /*sequence 
containing all identifiers associated with 
one statement*/ 

for build_identif ier_seq , check_dml_command, 

check_dml_keyword, build_keyword_seq, build_ 
list_seq, evoke_module , read_line, save__ 
subschema_inf o , save__subschema_privacy , save_ 
realm__info, save_realm_privacy , save_set_ 
info, save_set__privacy , save_record__info , 
save_record_j)rivacy , save__item__privacy , save_ 
error_table_inf o ; 

type list_itra_seq = sequence of text 

parametr : array Ci..§ of text ; /*list_item_name*/ 
end ; 

variable list_item_seq ; list_itm__seq; /*sequence 
containing all list items associated with one 
statement*/ 

for build list_item_seq , check__dral_command , 

check_dml_keyword, build_keyword_seq, build_ 
identif ier_seq , evoke_module , read_line; 

type keywrd_seq = sequence of records 

keyword; array [l. o^ text ; /*name of keyword*/ 
identif ier_counter ; integer ; /*contains number 
of identifiers (i.e., no. of times to read 
the identifier sequence associated with each 
keyword*/ 

end ; 

variable keyword_seq: keywrd_seq ; /*contains keyword 
number of identifier, associated with each 
keyword*/ 

for check_dml_command , check__dml_keyword, build_ 
keyword_seq, build_identif ier__seq, build_ | 
list__item_seq , evokejnodule , read_line, 
build_keyword_ seq, save__subschema_info, 
save_subschema_privacy , save__realm_info , 

Figure 3-2. (Continued) 
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save_realm_privacy , save_set_inf o , save_ 
set_privacy, save_record__inf o , save_record__ 
privacy, save_item__privacy , save_error_ 
table_inf o ; 

variable list_item__seq_ind ; integer ; /^indicates 
number of list items associated with a fetch, 
get, modify, or privacy statement, i.e., it 
indicates number of entries in the list item 
sequence*/ 

for check_dml_command , check_dml_keyword, build__ 
item_seq, evoke_module , read_line, save_ 
record_info, save_record_privacy , save_ 
item_privacy , initialize_system, build_dml_ 
table, build_keyword_table/ ; 
type subschema tabl= file of records 

subschema_name ; array text ; 

schema_name: array [^1. .:0 o^ text ; 
privacy_key: array o^ text ; 

dml_intrinsic : array Ql--0 of text ; 

/*dml intrinsic represents either the invoke 
or privacy statement*/ 

line_no; integer ; /*line number of dml command*/ 
end ; 

variable subschema table: subschema_tabl ; /*the sub- 
schema' table contains the subschema name and 
depending on the options exercised by the 
invoke and privacy statements, the schema 
name, and privacy key*/ 

for save_subschema_info , save_subschema_privacy , 
print__tables ; 

type realm_tabl - file of records 

realm_name: array [l. ^ text ; 

set_name: array (l. - ^ ^ text ; 

usage__indicator : integer ; /*indicates either 

protected, exclusive, concurrent and either 
retrieval or update 
Figure 3-2. (Continued) 
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error_handling : array [l. ^ text ; 
record_name ; array [l . . ^ text ; 
subschema_name ; array [l--§ ^ text ; 

privacy key : array Cl.,3] of text ; 
dml_intrinsic : array Q- • • ^ £f t ext ; 

/*dml intrinsic represents one of the 
following statements-ready , finish, find, 
fetch, or privacy*/ 

line_no; integer ; /*line number of dml command 
in listing*/ 

end ; 

variable realm_table: realm_tabl; 

for save_realm_info , save_realm_privacy , 
save_record_inf o , save_record_privacy , 
save_item_pr ivacy , print_tables ; 
type set tabl= file of records 

set_name; array of text ; 

record_name : array . sj of text ; 
mod_indicator : integer ;/*indicates that set 
relationship has been changed within the 
program* / 

privacy_key : array Ql . . s]] o^ text ; 

dml__intrinsic : array Ql.. 0 of text ;/* 

dml intrinsic represents one of the follow- 
ing statements-connect , disconnect, modify, 
find, fetch, erase, or privacy*/ 
error_handling : array of text ; 

record_delete_ind : integer ; /*0-indicates no 

record deletions, 1-indicates normal dele- 
tion, 2-indicates permanent deletion 3- 
indicates selective deletion, 4-indicates 
all deletion*/ 

subschema_name : array (l..^ of text ; 

line no: integer ; / *line number of dml command in 


listing*/ 

end ; 

Figure 3-2. (Continued) 
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variable set_table: set_tabl;/* the set table 
contains mainly set and record information 
depending on the options exercised by the 
connect, disconnect, modify, find, fetch, erase, 
or privacy statements*/ 

for save_set_info , save__record_inf o , save_set_ 
privacy, save_record_privacy , save_item_ 
privacy, print_tables ; 
type record tabl= file of records 

record_name: array Ql. of t ext ; 

set_name: array (^1. of text ; 

realm_name: array Ql..^ of text ; 

subschema_name : array Ql . . ^ o^ text ; 

modif icat ion_ind : integer ; /* indicates that 

set relationship has been changed within 
the program*/ 

error_handling : array [l..l0 of text ; 

data_base_key_name : array [_1. .:0 of text ; 

data_item_name : array [1..5, 1., 0 of text ; /* 

contains first five names in a list of 
data item names*/ 

privacy_key; array [l..^ ojE text ; 
dml_intrinsic : array Ql..0 of^ text ; /* 

dml intrinsic represents one of the 
following statements: find, get, fetch, 

store, modify, erase, connect, disconnect, 
or privacy*/ 

line_no: integer ; /*line number of dml command 

in listing*/ 

dml^stmt_ind : integer ; /*indicates privacy access 

by one of the following dml commands: insert, 
remove, store, modify, find, get, fetch, or 


erase*/ 

record_delete_ind : integer ; /*indicates that 
record is to be deleted*/ 


end 

Figure 3-2. 

i 
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variable record_table ; record_tabl ; /* the record 

table contains primarily record and set informa- 
tion depending on the options exercised by the 
find, get, fetch, store, modify, erase, connect, 
disconnect, or privacy statements*/ 
for save_record_info , save_set_inf o , save__set_ 
privacy, save_record_pr ivacy , save_item_ 
privacy, prlnt_tables ; 
type error status tabl= file of records 

procedure_name : array [l- text ; 

/* subroutine procedure which is to be 
called in the event a data base exception 
condition is encountered*/ 
all-indicator: integer ; /* the indicated pro- 

cedure will be called for all data base 
exception processing*/ 

other_indicator : integer ; /*the indicated pro- 

cedure will be called for any data base 
exception conditions which are not previous- 
ly established*/ 

status-indicator: integer ; /*the indicated pro- 

cedure will be called whenever any of the 
conditions in the associated status list are 
called*/ 

line_no: integer; /*line number of dml command 
in listing */ 

end ; 

variable error_status_table; error_status_tabl; /* 
the error status table contains information con- 
cerning the options exercised in the use state- 
ment*/ 

for save_err or_table_inf o , print_tables ; 
variable line-no-counter: integer ; /* contains line 
number of statement as it appears in the 
listing */ 


Figure 3-2, (Continued) 
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end; 


for check_dml_command, check_dml_keyword, 

build__keyword_seq , build_identlf ier_seq . 
build_list__item__seq , evoke_module , read_ 
line, save_subschema_info , save_subschema_ 
privacy, save_realm_inf o , save_realm_ 
privacy, save_set_inf o , save_set_privacy , 
save_record_inf o , save_record_privacy , save_ 
item_pr ivacy , save_error_table_inf o , 
init ialize__systera, build_dml_table , build__ 
keyword table; 


/+end of data description within the preamble*/ 
/*end of preamble for DBVS subsystem*/ 
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/^module description for dml recognizer and control module*/ 
module dml_recognizer ; 

fulfills check_dml__command , check_dml_keyword, 
build__keyword__seq , build_identif ier_seq , 
build_list_item_seq , evoke_module , read_iine ; 

/*initialize system*/ 

creates line_buffer, dml_intrinsic , keyword, list_ 
item, identifier, identif ier_seq , list_item_seq, 
keyword seq; 

/*read card and fill line buffer*/ 
accesses card_reader; modify line_buf f er ; 

/*det ermine dml command*/ 

modifies dml_intrinsic using line__buf f er , char_table, 
dml_command_table ; 

/*isolate dml keyword*/ 

modifies keyword using line_buffer, char_table, 
keyword table; 

/*construct keyword sequence*/ 
modifies keyword_seq using keyword; 

/*isolate identifier*/ 

modifies identifier using line_buffer, char__table; 

/*construct identifier sequence*/ 
modifies identif ier_seq using identifier; 

/*isolate list items lor dml statements*/ 
modifies list_item using line buffer, ch.ar_table; 


/* con struct list item sequence*/ 
modifies list_item_seq using list_item; 

Figure 3-3. DML - RFjCOGNIZER Module Description 
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end; 


Figure 


modifies list_item_seq_ind; 

executes conditionally 

subschema_process , realm_process , 

set_process, record_process , error_process , output 
summary ; 

executes initialize_system; 


3-3. DML-reCOGNIZEE Module Description (Continued) 

JI/ 
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/♦module description for initialize system^/ 
module initialize_system; 

fulfills initialize_system, build_dml_table , 
read_line, build_keyword_table ; 

create dml_command_table , charitable, keyword_table , 
lineiUOiCounter , list_item_seq_ind ; 

/♦construct dml command tables^/ 
modifies dml_command_table ; 

/♦construct char_table^/ 
modifies ch ar_t able; 

/♦construct keyword_table*/ 
modifies keyword_table; 

/♦initialize line number counter^/ 
modifies line_no_counter ; 

/♦initialize list item sequence indicator^/ 
modifies list_item_seq_ind; 

end; 


Figure 3-4. INITIALIZE-SYSTEM Module Description 

Jlr 
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/*module description for subschema processing*/ 
module subschema_process ; 

fulfills save_subschema_inf o , save_subschema_ privacy; 

creates subschema_table ; 

/*retrieve subschema, schema, privacy, or dis- 
play keywords*/ 

modifies keyword pging keyword_seq ©.keyword, keyword 
table 5 

/*r Btrieve subschema, schema or privacy key 
name* / 

modifies identifier using keyword_seq identif ier_ 

counter, identif ier_seq; 

/*construct record for subschema table*/ 
modifies subs chema_t able @ . subschema_name , 
subschema_table © . schema_name , 
subschema_table © .privacy_key , 
subs chema_t able © . dml_intrinsic , 
subschema_table ©.line_no using keyword, iden- 
tifier, dml__intrinsic , line_no_counter ; 

end ; 


Figure 3-5. SUBSCHEMA-PROCESS Module Description 
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/^module description for realm processing*/ 
module realm_process ; 

fulfills save_realm_inf o j save_realm_privacy ; 
creates realm__table ; 

/*retrieve all, set, realm, protected, concurrent, 
exclusive, retrieval, update, error keywords*/ 
modifies keyword using keyword-seq ©.keyword, keyword_ 
table; 

/*retrieve realm, set, subschema, error or 
privacy key name*/ 

modifies identifier using keyword-seq @ .identifier_ 
counter, identif ier_seq; 

/*construct partial record for realm table*/ 
modifies realm_table @ .realm_name , 
realm_table @ .set_name, 
realm_table @ .usage_indicator , 
realm_table @ .error__handling, 
realm_table @ .subschema_name , 
realm_table @ .privacy_key , 
realm_table @ .dml_intrinsic , 
realm_table line-no, using keyword, iden- 
tifier, dml_intrinsic , line_no_counter ; 

end ; 


Figure 3-6, REALM-PROCESS Module Description 



EEPRODUCIBILITY OF THE 


/*module description for set processing*/ 
module set-process; 


fulfills save__set_info , save_set_privacy ; 
creates set_table, record_table ; 


/♦retrieves record, all, set, error, only, sub- 
schema, order, connect, disconnect, permanent, 
selective, all, find, and fetch, keywords*/ 
modifies keyword using keyword_seq keyword, keyword 
table; 

/♦retrieve record, set, error, privacy, key, or 
subschema name*/ 

modifies identifier using keyword_seq @ . ident if ier_ 
counter, identifier seq; 


/♦construct partial record for set table*/ 
modifies set_table @.set_name, 

S6it_table @ .record_name , 
set_table @ . mod_indicator , 
set_table @ ,privacy_key , 
set_table @ .dral_intrinsic , 
set_table line-no, 
set_table @ . error_handling , 
set_table @ .subschema_name using keyword, 
identifier, dml_intrinsic , line_no counter; 


/♦construct partial record for record table*/ 
modifies record_table @ .record_name , 
record__table @.set__name, 
recor datable @ .modif ication__ind, 
record_table dml_intrinsic , 
record_table @.line_no using keyword, iden- 
tifier, dml_intrinsic, line no counter; 

Figure 3-7. SET-PROCESS Module Description 
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/^module description for record processing*/ 
module record process; 


Figure 


fulfills save_record_inf o , save_record_privacy , 
save_item_privacy ; 

creates record_table , set_table; realm_table; 

/*retrieve record, key, duplicate, any, set, 
using ^first , “last , next, prior, realm, offset, 
current, owner, rse , multiple, error, all, only, 
members, permanent, selective, all, subschema, 
insert, remove, store, modify, find, get, or 
fetch keywords*/ 

modifies keyword using keyword_seq ©.keyword, keyword_ 
table; 


/*retrieve record, key, set, using, offset, 
realm, rse, error, member or subschema name*/ 
modifies identifier using keyword_seq @ <.identif ier_ 
counter, identif ier_seq; 


/*construct partial 
modifies record__table @ 
record_table @ 
record_table @ 
record_table @ 
r e cor d_t able @ 
record_table @ 
record_table @ 
record_table @ 
record_table @ 
record_table @ 
record table @ 


record for record table*/ 
.record_name , 

.set_name, 

.realm_name , 
.subschema_name , 

.modif ication_ind, 
.error_handling , 
.database_key_name , 
.data_item__name , 
.privacy_key , 

.dml__intr insic , 

.line no , 


3-8 RECORD-PROCESS Module Description 
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record_table @ .dral_stmt_ind, 
record_table @ ,record_delete_ing using 

keyword, identifier, dml_intrinsic , line_ 
no_counter, list_item; 

/*construct partial record for set table*/ 
modifies set_table @.set_name, 

set_table @ .record_name , 
set_table @ .mod_indicator , 
set_table @ . dml_intrinsic , 
set_table @,line_no, 

set_table @ . record_delete_ind using keyword, 
identifier, dml_intr insic , line_no_counter ; 

/*construct partial record for realm table*/ 
modifies realm_table @ . realm_name , 
realm_table record_name , 
realm_table subschema_name , 
realm_table dml_intrinsic , 

realm_table @.line_no using keyword, identi- ' 
fier, dml_intrinsic , line_no_counter ; 

/*retrieve list items (actually data item names ) 
that have been saved as a result of a fetch, 
get, modify, or privacy statement*/ 
modifies list_item_seq_ind; 

end ; 


Figure 3-8. (Continued) 
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/^module description for error processing*/ 
module error process; 


fulfills save_error_table_info ; 
creates error__status_table ; 

/*retrieve procedure, all, other, status keywords*/ 
modifies keyword using keyword_seq ©.keyword, keyword_ 
table, 

/*retrieve procedure or status names*/ 
modifies identifier using keyword_seq identif ier_ 

counter, identifier__seq; 

/*construct partial record for error status table*/ 
modifies error_status_table procedure_name , 
error_status_table @ . all_indicator , 
error_status_table other_indicator , 
error_status_table © . status_indicator , 
error_status_table ©.line_no using keyword, 
identifier, line_no_counter ; 


end ; 


Figure 3-9. ERROR-PROCESS Module Description 


3-44 


/^module description for print process*/ 
module output_summary ; 

fulfills print-tables: 

/♦read and print subschema table records*/ 
access line-printer using' subschema_table ; 

/♦read and print realm table records*/ 
access line_printer using realm_table; 

/♦read and print set table x^scords*/ 
access line_j5r inter using set table; 

/♦read and print record table records*/ 
access line_printer using record_table , 

/♦read and print error status table records*/ 
access line_printer using error__status_table , 

end ; 

/♦end of main subsystem*/ 


Figure 3-10. OUTPUT- SUMMARY Module Description 


Table 3-15. Module Descriptions for the DBVS 


DML RECOGNIZER 


To isolate data manipulation language (DML) key- 
words and associated identifiers and list items. 
To construct appropriate keyword, identifier, and 
list item sequences. To evoke initialization or 
report modules, or to evoke appropriate DML state- 
ment processor modules . 


INITIALIZE SYSTEM 


To initialize the line number counter, the list 
item sequence indicator, and the following tables 
dral command, character, and keyword. 


SUBSCHEMA PROCESS 


To collect subschema information and enter it into 
the subschema table. 


REALM PROCESS 


To collect realm information and enter it into the 
realm table. 


SET PROCESS 


To collect set information and enter it into the 
set table. 


RECORD PROCESS 


To collect record information and enter it into 


the record table. 
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Table 3-15. (Continued) 
ERROR PROCESS 


To collect error information and enter it into 
the error status table. 


OUTPUT SUMMARY 


To read and print the following tables: subschema, 
realm, set, record, and error status. 




NOTES; 




"A" CALLS "B" 
CONDITIONALLY 



"A” USES SYSTEM SERVICE "B” 


SAI0474 


Figure 3-11. Module Structure Chart for DBVS 
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4. STATIC CODE ANALYSIS 


In this section, we present the detailed design (butld-to) 
specifications for the capabilities listed in. Table 4-1 which 
will be incorporated into FACES. For each of the twelve cap- 
abilities, we provide a detailed Unit Module Description in- 
cluding a flowchart which is sufficient for coding. However, 
for complete understanding of this documentation, the following 
FACES documentation must be used: 

• Version 2, Mod 0, Fortran Automatic Code Evaluation 
System SYSTEM DOCUMENTATION, September 1975, 

Browne and Ramamoorthy Inc . 

• Version 2, FACES User's Manual, September 1975, 

Browne and Ramamoorthy, Inc. 

• Version 2, Mod X FACES Program Listing 

The unit module descriptions correspond to those set forth in 
NASA's "Guidelines For Software Detailed Design Specification 
(C0[31C-T0) , " while the flowcharts follow ANSI FORTRAN flow- 
charting recommendations. The detailed specifications for the 
capabilities will appear in order according to Table 4-1. 

(New capabilities 5 and 6 capabilities 7 and 8 are treated 

under the same unit module description. 


REPRODUCIBILITY OE THU 
ORIGINAL PAGE IS POOH 
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TABLE 4-1. NEW FACES CAPABILITIES 


1. EQUIVALENCE and EXTERNAL statements are flagged. 

2. COMMONS not named are flagged. 

3. ALL COMMON BLOCK arrays must be dimensioned in 
COMMON BLOCK statements. 

4. DIMENSION statement and variable which contain 
an adjustable (variable) dimension are flagged. 

5. Constants, hollerith, or arithmetic expression 
arguments used in subroutine argument lists are 
flagged. 

6. All occurrences where the same variable exists in 
multiple positions in an actual parameter list are 
flagged. 

7. Arithmetic IPs are flagged. 

8. Targets of branches should not be other branches, 
especially single GO TOs . 

9. Variable which is I/O unit designator is flagged. 


JI/ 
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TABLE 4-1. NEW FACES CAPABILITIES (Cont.) 


10. Statement labels must appear in increasing order. 

11. Occurrences of error-prone FORTRAN statements such 
as ASSIGN statement, assigned GO TO, and PAUSE are 
flagged. 

12. The appearance of the same COMMON variable in more 
than one DATA statement is flagged. 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 


AIR Modifications 
STORAGE ALLOCATION 


IK hexadecimal bytes ’ * 

PURPOSE 

Process new query numbers for new FACES capabilities. 
DESCRIPTION 


These modifications cause AIR to recognize the new query 
numbers and call the new subroutine or modified subroutine 
as it processes original query numbers. 

now ENTERED 
Called by LNKAIR ’ 

CALLING SEQUENCE 
CALL AIR 

UNIT MODULE OR OTHER ROUTINES CALLED 


New Modules; 

ER23G 

ER275 


ER240 

ER280 


ER250 

ER290 


ER260 



Modified Modules: CONALC 

COMBAL 

MULBRA 


J7/ 
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SET/ USE PARAMETERS 


No new parameters are introduced NUMBER, the standard variable 
Tor query number is used. 

SIGNIFICANT INTERNAL VARIABLES 

No new variables are introduced. 

LIMITATIONS AND RESTRICTIONS 

All variables are set by IMPLICIT INTEGER (A-Z) . 

DETAILED FLOWCHART 

Only the modifications are included on the following flowchart. 
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UNIT MODULE DESCRIPTION 

IDENTIFICATION 

ER24Q — Error 240 routine 

STORAGE ALLOCATION REQUIREMENT (estimate) 

2K (hexadecimal bytes) 

PURPOSE 

FlaK EQUIVALENCE and EXTERNAL statements 
DESCRIPTION 

The routine checks each module for statement type. If type 
is a 12 (EQUIVALENCE) or 40 (EXTERNAL) the routine flags the 
statement in Flag File. 

now ENTERED 

Called by AIR 

CALLING SEQUENCE 

CaJ 1 ER240 
No Arguments 

ROUTINES CALLED 

JI/ 


IE 

GETE 

GETL 

POP 
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S];;T/USE parameters 


8ET 

Global: COMMON/ SPEREG/ 

ER(IO) — Error registers 

NOTE: Only ER(3) and ER(4) are set. 

FBR — forward/baekward register 

USE 

Global: COMMON/FLAG/ 

FLAGFL — input/output designator 

COMMON/ H/ 

ilB — hollerith B 

IIF — hollerith F 

COMMON/ TABLE/ 

HDIR -- directory table 
HUSEl — use table 
HSYM symbol table 
HNOD — node table 

SIGNIFICANT INTERNAL VARIABLES 


10, II, 13, 14 --- integer constants 

K — error flag 
SCIND — source code indicator 
FSTAT -- first statement number 
LSTAT — last statement number 
BF -- general purpose flag 
STATYP — statement type storage 
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LIMITATIONS AND RESTRICTIONS 


All variables are set IMPLICIT INTEGER (A-Z) 


DI'ITAILED FLOWCHART 


A L Lac hod 


Jlr 
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FtJIlMAT (!i(2», llii,2a) 

TII2-tO. . 

PAHAMC-TEH LIST; II, SCIND, 
rSTAT, LSTAT, K. 10, 10, 10, 10 





- • ‘ 
lli-i*. T. 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 

COMI3AL addition 

STORAGE ALLOCATION (estimate ) 

Additional 250 hexadecimal bytes 
PURPOSE 

Fiat’; unlabelled COMMON 
DESCRIPTION 

Tho routine contains a check on the Common Block name. If it 
is blank the statement is flagged, 

NOTE: There are no new variables and subroutines; there is 

only a new error message and an additional check. 

I).i'7L’AILED FLOWCHART 


So(i attachments 


Jj/ 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 


Modification to CONALC 
STORAGE ALLOCATION (estimate) 

Additional 500 hexadecimal bytes. 

PURPOSE 

Flag Common Block arrays that are not dimensioned in Common 
Block statements. 

DESCRIPTION 

The modification locates the source and writes a message to 
FLAG FILE to indicate that an array in a COMMON BLOCK is 
dimensioned elsewhere. 

HOW ENTERED 

The code occurs at the point where a Common Block variable is 
dlmcn.sioned other than in a Common Block. 

DETAILED FLOWCHART 

See attachments. 

JI/— 
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ALL COMMON CLOCK ARRAYS 
MUST BE DIME?’S)1NED IN 
COMMON BLOCff LRRAY (270) 


REPRODUCIBILITY OE ii. v. 
ORIGINAL PAGE IS POOR 


801 FORMAT (5(2x, 15). 'CONALC. /, 4(2x,l5)) 
I/O PARAMETER LIST: 

II. SCIND(l), FSTAT(I), LSTAT(I). 

10 , 10 , 10 , 10 


SAI0461 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 

ER275 

STORAGE ALLOCATION (estimate) 

2K (hexadecimal bytes) 

PURPOSE 

Flag DIMENSION statement and variable which contains an 
adjustable (variable) dimension . 

DESCRIPTION 

This subroutine searches a module for statement type 28 
(DIMENSION) then examines each array element for a use code 
1.5 (Array dimension). When this condition exists the error 
is recorded. At the end of the statement search each array 
is flagged that has a variable dimension. 

HOW ENTERED 

Called by AIR subroutine if query is selected. There are no 
a.rguments . 

CALLING SEQUENCE 
Call ER275 

OTHER ROUTINES CALLED 
IE 

GETE 

GETL 

TT 

JI/— 
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SET/ USE PARAMETERS 


USE 

COMMON/ FLAG/ 

FLAGFL — I/O designator 

COMMON/ H/ 

HB — hollerith B 
HF — hollerith F 

COMMON /TABLE/ 

HDIR — directory 
HUSE2 — linked Test Statement 
HUSEl -- linked List Use 
HNOD — Node Table 

COMMON/ SPEREG/ 

ER(IO) -- table information turn array 
FBR — program flow register 

SIGNIFICANT INTERNAL VARIABLES 

10, II, 12, 13, 14, 15, 16, 17, 18, 19 = 0 - 9 

K — error flag number 

SCIND — module indicator 

FSTAT — first statement number of error 

LSTAT — last statement number of error 

NUMOCC -- counter for error 

RESTRICTIONS 

All variables are IMPLICIT INTEGER (A-Z) 

DETAILED FLOWCHART 
Attached 

JI/ 
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> 




NUMOCC 0 
Sr T COUNTER TO 
2ER0 FOR U 
or ERROR EVENTS 







ri 

(USE?. IlFI 
LINK 10 USE 
TAItLE FOR IHIS 
ST ATEMENT 


CUf CK r ACll fcl fM6Nr 
FOR VARIAHUF USED 
AS AN ARRAY DIMENSION 
USE 15 



SF.r FLOW TO 
backward 

FBR • HB 




I ^ 

IHSYM. BFI 
TRANSFER TO 
SYMBOL TABLE 


sei FLOW 

^/endof 

VYES 

POP (BF) 
MOVE SYM 

FLAG TO 

<C TABLE 


UP IN 

FORWARD 

BF.EQ.2 . 


CONTROL 

rflH-HF 



STACK 

\ 




oriF 

lusr?. o) 

CHECK NFXr I NIRY 
IN STAICMENT 


,* i.L imsN, 
NOT ARRAY 
simscMifr 
\ JRII3LNE.15 



SET FLOW TO 

1 

U 

BACK 
FHH • HH 



ERROR HAS OCCURRED 
FIND VARIABLE NAME 
AND WRITE THE NAME, 
LOCATION 8f ERROR II 
TO FLAG FILE. KEEP 
CHECKING STATEMENT 


GETE 
(HSYM. ID 
GET SYMBOL 
NAME 


SAVE NAME 

SVNM1 ' ER(I3) 

SVNMZ * 

-ER (141 




WRITE I LAGFL; 
THAT ARRAY 
HAS VARIABLE 
/DIMENSION 


I r>01 FOI^MAT (5(?X. 15I, 
('ER275. . 3l2x, I5),1X. 2A41 

PARAMETER LIST: 11. 
SriND, FSTAT. LSTA1 
K. NUMOCC. 10. 10. 
SVNM1.SVNM2 




BEPRODUCIBILITY OF THE 
OBIGINAI. PAGE IS POOR 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 

ER280 

STORAGE ALLOCATION (estimate) 

PURPOSE 

Flags subroutine calls with constants and hollerith arguments 
and flags all occurences where the same variable exists in 
multiple positions. 

DESCRIPTION 

This routine searches the parameter list of each CALL statement 
(statement type 34) for either equal variable symbols or 
constants (symbol class 8) and holleriths (symbol type 6) used 
as an entire argument (uSE table use code 19 and 17). 

HOW ENTERED 

Called by AIR subroutine 

CALLING SEQUENCE 
Call ER280 (QNUM) 

QNUM is the query number = 280 or 285 

OTHER ROUTINES CAl.LED 
IE 

GETE 

GETL 

CONALP 

POP 
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SET/ USE PARAMETERS 
USE 

GLOBAL: COMMON/ AL INFO/ 

COMMON/FLAG/ 

FLAGFL — input /output ti^’signator 

COMMON /H/ 

HB — hollerith B 
HF — hollerith F 

COMMON /SPEREG/ 

ER(IO) — Error registers 

NOTE: Only ER(3) and ER(4) are set. 

FBR — forward/backward register 

COMMON /TABLE/ 

HDIR -- directory table 
HUSEl -- use table 
HSYM — symbol table 
HNOD -- node table 


SIGNIFICANT INTERNAL VARIABLES 

OVFLG — Output variable from CONALP ; table overflow 
ERFLG -- Output variable from CONALP; error flag 
PTR — Input variable to CONALP; pointer to statement 
10, II, 19 — represent integers 1-9 

K — error flag 
SCIND — source code indicator 
FSTAT ' — ;j^irst statement number 
LSTAT -- last statement number 

BF — general purpose flag 
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tM2B» ^ 
(QNUM) J 


INfltAUZE 

constant:: 

10. M.. . . fH 
0. t 8 


Sf r PRROR 
NtJMBER TO 
OlJf HY 
NUMoen 

ASSOCIATED WITH IT 
WITH IT 
K QNUM 


lunniNi i'iuk;i ssrs query 280. 28 s: 2 «o fi.ags 
CONM ant;, and HOLLERITHS. 28A DUPI ICATE 
VARIAfM f NAMES IN ACTUAL SUBROUTINE 

/ALl/./H/, /FI AG/. /SPEREG/./TAB) E/ 

/AUNFO/ • 



GETr 
oiDin, la) 
GET MODULE 
NUMBER 
(EH(I3) 



GETE 
IHNOD, 17) 

GET 

SIATEMENT 
1st LOCATION 




. 

; 


YE-S 

Milt tilt 
SI niACKWARD/ 


FORWARD 


FSTAT (II) » 
SET FIRST 
LOCATION 


ER(I3) 


GF 1 1 
(RF) 

ilHlNG MODULE 
INTO Ml MORY 





GHE 
IHDIR, 14} 

getch source 

CODE 

INDICATOR 


GETE 
(HNOD, 13) 
GET LAS’ 

location 


L:.TA7 (ID * ER (13) 
SET LAST 
SIATEMENT 
I OCATION 




■OF THE 


niHfO? 
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ENTRV \ 
BFF0.2 TRY 
ANOTHER 
STATEMENT 


S( I I I OW 
FLAG TO 
BACK FBR -HB 


/WAS THFRE\ 
AN ERROR IN 
CONALP 
\ERFG.EO.t/ 


WRITE TO 
PRNTFL 
SUBROUTINE 
PARAMETER 
CHECK OVER 


FBR » HB 
■ FLOW 
BACKWARDS 


/ ISTHFRE \ 
AN OVERLFLOW 
\0VFG EO.1/^ 


WRITE TO 
PRNTFL THAT 
CHECK MAY 
NOT Ilf VALID 


CHECK FOR WHICH COMPARISON f.' '.0 UE 
MADE. THEN SEARCH PARAMETER LIST FOR 
THAT .SITUATION, ONLY ALIGNMENT LIST I 
IS USED. 


/IS IHIS\ 
CONSTANT 
HOLLERITH 
, CHECK I - 
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CONSTAN1/nOi LERITH 
CHECK 


SET FOR TABLE 
CHECK 

PM ' 3. PCI -4 
HI 1 “ PLALKl) 
ERCNI -0 


221 FORMAT 
(5(2XJ5|, 2X/ER280.. .‘, 

3(2x. I51.2A4L I/O LIST: 12. 
SCINOd). FS I ATM). LSI 'TflJ. K 
ERCNT, 10. to, NAME 


/ ENOOF \ 
PARAMETER 
LIST PTt 


^ANY ERRORS^ 
THIS LIST 
‘ ERCNT, . 
\ GT.O / 


/WRITE FLAG 
I FILE. lOCATION 
NAME. TYPE j 
ERROR, ERCOUNt/ 


SET FLOW 
TO BACK 
FRR - HB 


i;; THIS A \ 
HOI I ERITM 
PARAMETER 
ALIGN (1. PTH. 
\ EQ.6 / 


INCREMENT 
ERROR 
COUNT ER 
ERCNT ' ERCNT 1 


/ IS IMIS A \ 
CONSTANT ^ 
PARAMETER 
ALIGN II, PCI). 
EQ.H / 


.INCREMENT 
ERROR COUNT 
ERCNT - ERCNT H 


■,( f POINrCHS lO 
NEXT PARAMETER 

PI 1 Pill I ABI S lAI ION n. PTl I l))‘3 ' 
P''1 • PI1 ' I 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 
MULBRA additions 

STORAGE ALLOCATION REQUIREMENT ( estimate) 

Total after additions 2K hexa, decimal bytes 
PURPOSE 

Flag arithmetic IFs and flag GO TOs that are targets of other 
GO TOs. 

DESCRIPTION 

One addition to MULBRA will flag GO TO statements which are 
the targets of previous GO TO statements. The program will 
search for statement type 45 that has a use code of 9. When 
this occurs the statement is flagged with a message to the 
Flag File (220). 

The second addition to MULBRA flags Arithmetic IFs. In this 
case an IF statement (statement type 10) with more than 2 
branch targets is flagged by an error message to the flag 
file (220). 

HOW ENTERED 

Called by AIR upon query request. 

CALLING SEQUENCE 


CALL MULBRA (Number) 

Number is query number 150, 200, or 220; all are processed 
in this subroutine. 
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X 


N(Mi ONI Y nil AUf)IIION5; AHI 
••CODI H>*'OrrAH 


MUl llltA 
(NUMnr II) 


IMN ICIT INTlOnt (A /) 

I AIll LIFI) COMMON/ri Aa/./ll/./SI>tRL«/,yrAHLE/ 

NiJivmrn us possnue ouery i*>o. ?oo. 2?o 

INCLUDES SEARCH FOR ARITHMETIC IFS AND 
OOTOS THAT ARE TARGETS OF OTHER GOTOS 


INIMAl l/i 
CflNSFANKI 
AND DHU CHON 




fNIHAl.l/l 
rOR ENTIIY 
TO DIRECTORY 


''HAVE ALL^ 
MODULES 
BEEN 

.EXAMINED^ 


BRING MODULE 
INTO MAIN 
MEMORY 


FIND SOURCE 
CODE INDEX 



RRING IN A 
STATEMENT 


ARE ALL 
EXAMINED? 


SFT 

STATEMENT 

TYPESTATYP 


RESET 

RRANCH FLAG 
TO ZERO 
UFLAG - 10 


RTSET TARGET 
COUNT I lag 
TO /TRO 
NSUC ' 10 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 

ER250 — Error 250 Routine 

STORAGE ALLOCATION (estimate) 

2K (hexadecimal bytes) 

PURPOSE 

To flag variables used as I/O designators. 

DESCRIPTION 

This routine examines each line of code in the source decks 
for variables with the classification "scalar" (class code = 6) 
which are also used as I/O designators (use code = 26). Having 
found one which satisfies both requirements, an applicable 
message is written to the flag file. 

MATHEMATICAL EQUATIONS/DEFINITIONS 

None 

HOW ENTERED 
Called by AIR 
CALLING SEQUENCE 

Subroutine call, no arguments. Call ER250. 

UNIT MODULE OR OTHER ROUTINES CALLED 
IE 

GETE 

GETL 

TT 
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SET/ USE PARAMETERS 
SET 


Global Common: COMMON/ SPEREG/ 

ER(IO) — Error registers 

NOTE: Only ER(3) arAd ER(4) are set. 

FBR — forward/backward register 
USE 

Global Comnion: COMMON/FLAG/ 

FLAGFL -- input/output designator 

Global Common: COMMON/H/ 

HE -- hollerith B 
HF — hollerith F 

Global Common: COMMON/TABLE/ 

HDIR — directory table 
HUSEl — use table 
HSYM — symbol table 
HNOD — node table 

SIGNIFICANT INTERNAL VARIABLES 

10, II, . . . , 19 — represent integers 1-9 
K — error flag 

SCIND — source code indicator 
FSTAT — first statement number 
LSTAT — last statement number 
BF — general purpose flag 
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Jlr 


CONSTRAINTS 

All variables are set to integer by the IMPLICIT statement. 

COMPUTATIONAL ACCURACY AND RANGE OF INPUT/OUTPUT VARIABLES 

Non -Applicable 

ERROR MESSAGES AND SUMMARY 

None 

DETAILED FLOWCHART 
See following pages. 


JI/ 
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SET STANDARD 
INTEGER VALUES 

10, II 19 

^ 0. 1 9 


VARIABLE WHICH IS I/O UNIT DESIGNATOR 
IS FLAGGED: SEARCH FOR SCALARS (CLASS 
CODE = 6) WHICH ARE USED AS I/O UNIT 
SPECIFICATIONS (USE CODE = 26). USES 
NAMED COMMON/FLAG/./H/,/SPEREG/8,/TABLE/ 
IMPLICIT INTEGER (A -2) 


SET ERROR 
FLAG NO. 

K 250 


SET FORWARD/ 
BACKWARD FLAG 
TO FORWARD 
FBR = HF 


IE 

(HDIR, 8F) 
BRING IN A 
MODULE TO 
SEARCH 




SET FORWARD/ 
BACKWARD FLAG 
TO FORWARD 
FBR ’ HF 


END\ 

/OF MODULE^/ 
FLAG is 2 \ 

LEAVE SUBROUTINE 
\ BF.EQ.2 / 


GETE 
(HDIR, 13) 

FIND END OF THIS 
MODULE 


END OF THIS 
MODULE? 
-ER(I3) >10 ^ 


SET FORWARD/ 
BACKWARD FLAG 
FBR = HB 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 

ER260 -- Error 260 routine 

STORAGE ALLOCATION (estimate) 

2K (hexadecimal bytes) 

PURPOSE 

Flag statement labels not in increasing numerical order. 
DESCRIPTION 

This routine locates and reconstructs each statement label in 
a module. If the current label is less than the previous 
label it is flagged. 

HOW ENTER ED 
Called by AIR 

GALLING SEQUENCE 

Subroutine: Call ER260 

There are no calling arguments 

UNIT MODULE OR OTHER ROUTINES CALLED 


SUBROUTINE: IE 

GETE 

GETL 

CONVER 

FUNCTION: FLD 

J7/^ 
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SET/USE PARAMETERS 


Global ; COMMON/ SPEREG/ 
ER(IO) 


GLOBAL: COMMON/FLAG/ 


Flagfl — I/O file 


NOTE: Only ER(3) is set, 

the rest are not 
referenced. 


COMMON/ HOSTWD/ 

FULLWD 
COMMON/ H/ 

HB — hollerith B 
HF — hollerith F 

COMMON/ TABLE/ 

HDIR 

HSYM 

HNOD 


SIGNIFICANT INTERNAL VARIABLES 


10, II, ... 19 — integers 1-9 
LSAVE — current label number 


SCIND 


— error number flag 

— source code indicator 

-- first statement number of error 

— last statement number of error 

— condition flag; return argument 

— next reconstructed label number 
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SET STANDARD 
INTEGER VARIABLES 
10,11 19 = 0, 1 9 


SET LOCAL 
VARIABLE 
LSAVE = 0 


SET FORWARD/ 
BACKWARD 
flag FBR = HF 


SET ERROR 
INDICATOR 
K = 260 

IE 

(HDIR, BF) 

BRING IN MODULE 
TO SEARCH 


ItEPKODTJCIBILITy OF 1 
OEIGWAL PAGE I& P ■■ 


SET FORWARD/ 
BACKWARD FLAG 
TO FORWARD 
FBR = HF 



SA|,0458 













SAI 0456 






c 



I 


I 
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1001 FORMAT (5{2X, 15), 2X, 'ER260. 
3(2x, 15), 2x, 2A4) 

I/O PARAMETER LtST; II, SCIND, 
FSTAT, LSTAT, K, lO, lO, lO, 10 


SAI-04S9 
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UNIT MODULE DESCRIPTION 


IDENTIFICATION 

ER230 Error 230 routine 

STORAGE ALLOCATION (estimate) 

3K (hexadecimal bytes) 

PURPOSE 

Flag ASSIGN, PAUSE and assigned GO TO statements 
DESCRIPTION 

This routine searches a module for statement 38 (ASSIGN) j 
50 (PAUSE), or 45 (GO TO). When the first two are found, the 
error is written to Flag File immediately. The third one 
is checked further for a use code of 23 (transfer through a 
variable value). If the code is 23 a message is written to 
the Flag File also. 

HOW ENTERE D 

Called by AIR 

CALLING SEQUENCE 
CALL ER230 

Note: No arguments are used. 

UNIT M ODULE OR OTHE R ROUTINES CALLED 
IE 

GETE 
GETL 
FELUSE 


Jlr 
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SET /USE PARAMETERS 


GLOBAL : COMMON/ SPEREG/ 

ER(IO) — error 

registers 

NOTE; Only ER(3) 

is used 

FBR — forward/ 

backward register 


GLOBAL: COMMON /FLAG/ 

FLAGFL — I/O de- 
signator 

COMMON/H/ 

H3 — hollerith B 
HF — hollerith F 

COMMON /TABLE/ 

HDIR — directory 
table 

HNOP — node table 

HSYM — symbol 
table 

HUSEl — use table 


SIGNIFICANT INTERNAL VARIABLES 


10, II, . . . , 19 - 


SCIND 

FSTAT 

LSTAT 


STATYP 

A(10) 


— represent integers 1-9 

— error flag 

— source code indicator 

— first statement number 

— last statement number 

— general purpose flag 

— statement type 

— array for return arguments 


CONSTRAINTS 


All variables are set to integer by IMPLICIT statement 


DETAILED FLOWCHART 


See attached 
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UNIT MODULE DESCRIPTION 


IDENTIEICATION 

ER290 

STORAGE ALLOCATION REQUIREMENTS (estimate) 

4K hexadecimal bytes 

\ 

PURPOSE 

Flag COMMON variables multiply defined in DATA statements. 
DESCRIPTION 

This routine examines all COMMON blocks. Each module containing 
that COMMON block is examined for DATA statements. At this 
point the parameter in the COMMON block is compared against the 
parameters in the DATA statements. A record is kept only for 
each module of multiple definitions. Multiple definitions will 
be written on the FLAG FILE. 

HOW ENTERED 

AIR subroutine calls this subroutine when query 290 is requested 

CALLING SEQUENCE 
CALL ER290 

ROUTINES CALLED 

IE 
POP 
PUSH 
TT 

JI/-^ 


CONALC 

CONALP 

EQUIVL 

GETE 
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SET /USE PARAMETERS 


SET 

GLOBAL; COMMON/ SPEREG/ 

FBR — program flow flag 

COMMON/ ALINFO/ 

NAME(2) — name save variable 
MNAME(2,2) — module name save variable 
SCIND(2) — source code index 

FSTAT(2) — first statement number of source code 
modules 

LSTAT(2) — last statement number of source code 
modules 

NUMOCC —error counter 


USE 

GLOBAL; COMMON /ALI/ 

ALIGN (2, 300) alignment table 
PLALI(2) — alignment table indicators 

COMMON/ FLAG 

FLAGFL — I/O variable for error information 
COMMON/ H/ 

HB — hollerith B 
HF — hollerith F 

COMMON/ LTS/ 


LISTAB(500) 

— list 

of equivalenced variables 

LLIS 

— list 

table pointers 

PLLIS 

— list 

table pointers 

MAP(6» 20) 

— list 

table map 

PMAP 

— list 

table map pointer 

PLMAP 

— list 

table map pointer 
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COMMON/ SPEREG/ 


ER(IO) — ■ table information storage 


USE 

COMMON/ TABLE/ 

HCOM — hollerith COM for Common block table 

HDIR — hollerith DIR for Directory 

HMAP — hollerith MAP for Map table 

HNOD — hollerith NOD for Node table 

HSYM — hollerith SYM Symbol table 

HUSEl — hollerith USEl Use table 

HUSE2 — hollerith USE2 for table 

SIGNIFICANT INTERNAL VARIABLES 

AM — Indicates which alignment table to be filled 
OVFLAG — overflow flag for tables 
ERFLAG — irretrieveable error flag 
ERINC — counts 290 error occurrences 


LIMITATIONS AND RESTRICTIONS 

All variables are set with IMPLICIT INTEGER (A-Z) 

DETAILED FLOWCHART 

Attached 

TiF 


BEPRODUCBlLin OF 

okiginal page is p< 


JI/ 
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LOOK AT 
NEXT L!ST 
ITEM 

ERCN'r - 0 


POP 

PLACE ITEM 
TOP OF 
CONTROL 
STACK 


EQUIVAL 

(LISTIVO. 

OVERFL) 

GET LIST OF » 
NAMES 


E XAMINE NF XT MODULE 
COMMON BLOCK IS IN 
cm CK PARAMETER AGAINST ■ 
VARIABLES IN DATA 
STATEMENT 


TABLE \ 
OVERFLOW? 
OVERFL, EQ.1 


TT 

(HLIN, BF) 
EXAMINE 
LIST OF 
MODULES 


/WRITE 
' PRNTFL 
OVERFLOW 
MAY NOT BE/ 
100 % / 


SET FLOW 
FLAG 
FBR = HB 


SET FORWARD 
FLAG FORWARD 
BFR = HF 


END OF 

MODULE? 

BF.EQ.2 


INCREMENT 

parameter 
LIST POINTERS 




CALLGETE 
(HLIN, II) 

GET MODULE 
REFERENCES 
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